Filing pack for generative AI services and algorithm filing, including the security assessment report

Structure (10 sections)

1. 1. 1. Applicability: public-opinion attributes or social-mobilisation capability

   Filing and security assessment are triggered where the service has public-opinion attributes or social-mobilisation capability. Art. 2 of the Provisions on the Security Assessment of Internet Information Services with Public Opinion Attributes or Social Mobilisation Capability defines these as two situations: operating forums, blogs, microblogs, chatrooms, communication groups, public accounts, short video, live streaming, information sharing, mini-programs and similar information services, or adding such functions; and operating other internet information services that provide a channel for public expression of opinion or that are capable of mobilising the public to engage in particular activities. Art. 3 then lists five situations in which a provider must carry out a security assessment on its own initiative: launching such an information service, or adding such a function to an existing service; using new technologies or applications such that the service’s functional attributes, technical implementation or basic resource configuration change materially and its public-opinion attributes or mobilisation capability change materially as a result; a significant increase in user scale producing such a material change; the spread of unlawful or harmful information indicating that existing safeguards cannot effectively control cybersecurity risk; and other situations notified in writing by a municipal-level or higher cyberspace authority or public security organ. For AI companies, public-facing conversational products, content-generation platforms and applications with community or distribution features are usually caught; purely internal enterprise deployments not offered to the public generally are not, though opening a public trial entry point can change the analysis. Record the determination, its basis and who made it — everything else rests on it.

   Evidence to attach

   • · Determination record against the two situations in Art. 2 and the five in Art. 3
   • · Product function inventory and who it is offered to (consumer / business / internal)
   • · Description and screenshots of any public trial entry, community features or content distribution
   • · User-scale statistics and growth records, where Art. 3(3) is in play
   • · Any written notice received from the competent authority

   Common pitfalls

   • · Concluding "we are business-only" while the product has a public trial page or shareable generated output;
   • · Making the determination once at first launch and never revisiting it after community, sharing or subscription features are added;
   • · Ignoring Art. 3(3) after user scale grows significantly;
   • · No written record of the determination, leaving nothing to explain the original reasoning at inspection.

2. 2. 2. Filing entity and service information (Art. 24, Algorithmic Recommendation Provisions)

   Art. 24 sets out what must be filed through the internet information service algorithm filing system: the provider’s name, the form of the service, the application field, the algorithm type, the algorithm self-assessment report and the content to be published, among other items. The deadline is **within ten working days of the day the service starts**, which means filing must be scheduled alongside the launch plan rather than started after go-live. Art. 25 provides that where the materials are complete the authority grants the filing, issues a filing number and publishes it within thirty working days, and where they are incomplete it refuses the filing and notifies the applicant with reasons within thirty working days. The output here is a filing worksheet: entity information (name, unified social credit code, registered address, ICP licence or filing status, responsible person and contacts); service information (service name, form — website, app, mini-program, API — application field, launch date, user scale); algorithm information (name, type, purpose, an outline of how it works); and the content to be published (the public-facing version, worded consistently with the actual product and free of trade secrets). Keep the filing consistent with the corporate registration, the ICP filing and the product as actually shipped — inconsistency is the most common reason a filing is refused.

   Evidence to attach

   • · Filing worksheet covering the entity, service, algorithm and to-be-published content
   • · Business licence, unified social credit code certificate and ICP filing or licence
   • · Evidence of the service launch date (release records, app-store listing date, announcements)
   • · Internal schedule against the ten-working-day deadline and the actual submission date
   • · Legal and business sign-off on the content to be published
   • · Submission receipt and status screenshots from the filing system

   Common pitfalls

   • · Counting the ten working days from when the pack is ready rather than from the day the service starts, which routinely overruns;
   • · An entity name inconsistent with the business licence or the ICP filing holder, common where group companies operate each other’s products;
   • · To-be-published content so general that it does not match the shipped product, prompting a correction request;
   • · Treating the thirty working days after completeness as preparation time you can spend freely.

3. 3. 3. Algorithm self-assessment report

   The algorithm self-assessment report is one of the items Art. 24 lists. Cover two lines: the algorithm and its governance. Algorithm: name and version; type (generative or synthetic, personalised push, ranking and selection, retrieval and filtering, scheduling and decision); an outline of its principles and mechanism; input features and output form; training-data provenance and scale; evaluation method and headline metrics; and known limitations and failure modes. Governance: the management systems established under Art. 7 in discharging primary responsibility for algorithm security — review of algorithm mechanisms, science and technology ethics review, user registration, review of published information, data security and personal information protection, countering telecom and online fraud, security assessment and monitoring, and emergency response to security incidents — and how they operate; the arrangement under Art. 8 for periodically reviewing, assessing and verifying the algorithm mechanism, models, data and application results, with the latest outcome; user-model and user-tag management under Arts. 9 and 10; the transparency notice, the non-personalised option and the one-click off switch under Arts. 16 and 17; and the specific protections for minors, the elderly, workers and consumers under Arts. 18 to 21. Generative services should also cover training-corpus lawfulness, labelling governance and content-safety measures, for which GB/T 45654-2025 on basic security requirements for generative AI services is the common reference. The algorithm self-assessment and the security assessment below can share evidence, but they differ in conclusion and perspective: the first looks at the algorithm, the second at the security of the service as a whole.

   Evidence to attach

   • · The full algorithm self-assessment report, in its algorithm and governance halves
   • · The eight Art. 7 management systems and evidence they run (approval trails, minutes, training sign-ins)
   • · The Art. 8 periodic review, assessment and verification plan and the latest report
   • · User-tag scheme and the technical measures keeping unlawful or harmful information out of interest profiles
   • · Transparency notice text, and screenshots of the non-personalised option and the one-click off switch
   • · Evidence of the specific protections for minors, the elderly, workers and consumers
   • · Self-check matrix and gap list against GB/T 45654-2025 for generative services

   Common pitfalls

   • · A self-assessment describing the technical design only, with no governance systems or execution records;
   • · Eight management systems that exist as documents with no trace of operation;
   • · A one-click off switch buried several menus deep, or personalisation continuing after it is used;
   • · A periodic review mechanism described but never producing a single report;
   • · A generative service with no self-check against GB/T 45654-2025, leaving the corpus and content-safety sections hollow.

4. 4. 4. Security assessment report (Arts. 5 and 6, Security Assessment Provisions)

   Art. 4 lets the provider run the security assessment itself or engage a third-party assessment institution. Art. 5 requires a comprehensive assessment of the lawfulness of the service and of any new technology or application, the effectiveness of the security measures required by laws, administrative regulations, departmental rules and standards, and the effectiveness of risk control, with **particular attention** to eight items: appointing a security management officer and information reviewers, or establishing a security management body, commensurate with the service; real-identity verification of users and retention of registration information; retention of log information — user accounts, operation times, operation types, network source and destination addresses, source ports, client hardware characteristics — and of records of information users publish; prevention and disposal of unlawful and harmful information in user account and communication-group names, nicknames, profiles, remarks and identifiers and in publishing, forwarding, commenting and communication-group functions, and the retention of related records; technical measures for personal information protection and for preventing the spread of unlawful and harmful information and loss of control over mobilisation functions; establishing complaint and reporting systems, publishing the channels, and accepting and handling complaints and reports promptly; establishing a working mechanism to provide technical and data support and assistance to cyberspace authorities in their supervision of internet information services; and establishing a working mechanism to provide technical and data support and assistance to public security and state security organs in safeguarding national security and investigating offences. Art. 6 requires latent risks found to be rectified promptly until eliminated, and, where the assessment shows conformity with laws, administrative regulations, departmental rules and standards, a security assessment report containing four things: the basic profile of the service — functions, service scope, hardware and software facilities, deployment locations — and the licences obtained; the implementation of security management systems and technical measures and the effect on risk control; the assessment conclusion; and any other matters to be explained.

   Evidence to attach

   • · The security assessment report structured on the four Art. 6 items and covering the eight Art. 5 focus areas
   • · Appointment documents, headcount and shift rota for the security officer and information reviewers
   • · Real-identity verification design and success-rate statistics
   • · Log retention configuration (fields, period) and sampled verification
   • · Technical design and disposal register for unlawful and harmful information
   • · Screenshots of the complaint and reporting entry point, with intake times and outcome statistics
   • · Documents and named contacts for the cooperation mechanisms with cyberspace, public security and state security organs
   • · Remediation register (risks found, measures, evidence of elimination)
   • · The third-party institution’s credentials and report, where engaged

   Common pitfalls

   • · Missing one of the eight focus areas — most often incomplete log fields, or no concrete arrangement for assisting enforcement;
   • · A report stating that systems exist without the Art. 6(2) account of implementation and its effect on risk control;
   • · Reviewer headcount plainly mismatched to service scale (millions of daily users against a handful of reviewers);
   • · A complaint channel with no handling-time data, so "prompt acceptance and handling" cannot be shown;
   • · Issuing the report with remediation still open, contrary to the Art. 6 requirement to rectify until eliminated.

5. 5. 5. Training corpus and data-labelling governance materials

   Corpus lawfulness draws the most questions in the filing and security assessment of a generative service. Under Art. 7 of the Interim Measures, a provider conducting pre-training, optimisation training and other training-data processing must: use data and foundation models from lawful sources; not infringe intellectual property rights others hold by law; where personal information is involved, obtain the individual’s consent or meet another situation prescribed by law or administrative regulation; take effective measures to improve training-data quality and enhance its veracity, accuracy, objectivity and diversity; and comply with the Cybersecurity Law, Data Security Law, Personal Information Protection Law, other laws and administrative regulations, and the requirements of the competent authorities. Art. 8 requires clear, specific and workable labelling rules consistent with the Measures, quality assessment of the labelling with sampled verification of accuracy, and necessary training, supervision and guidance for labellers. Art. 19 of the Network Data Security Management Regulations adds a dedicated rule: a network data processor providing generative AI services must strengthen the security management of training data and training-data processing and take effective measures to prevent and handle network data security risks. Art. 18 constrains how the corpus is gathered: a processor using automated tools to access or collect network data must assess the impact on the network service, must not unlawfully intrude into another party’s network and must not interfere with the normal operation of the service — the compliance statement for crawled corpora should address that provision head-on. For the pack, build one register and four statements: a corpus register (source, how obtained, licence basis, scale, modality, whether it contains personal information, whether sensitive, and the cleaning and filtering applied); a source-lawfulness statement; an intellectual property risk statement including the rightsholder complaint and removal mechanism; a personal information lawfulness statement cross-referenced to the PIPIA; and a labelling governance statement covering rules, quality assessment method, sampled verification results and labeller training records.

   Evidence to attach

   • · Training-corpus register with the fields above, one row per dataset
   • · Foundation-model provenance and licence, including whether commercial use and redistribution are permitted
   • · Data purchase contracts and the vendor’s rights warranties
   • · The IP complaint and removal mechanism and its handling register
   • · Personal information lawfulness statement, cross-referenced to the PIPIA
   • · Labelling rules, quality assessment method and sampled verification records
   • · Labeller training records and the supervision arrangement
   • · Corpus cleaning and harmful-content filtering design and its effectiveness evaluation

   Common pitfalls

   • · A corpus register at dataset-name granularity that cannot explain provenance or licence basis;
   • · A foundation-model licence prohibiting commercial use or requiring attribution that is not honoured in practice;
   • · Labelling rules existing only as verbal convention, with no text, no training records and no sampled verification;
   • · No IP complaint mechanism, or an unreachable one, leaving rightsholders to go straight to the regulator;
   • · Personal information in the corpus not reconciled with the PIPIA, so the two documents describe the same facts differently.

6. 6. 6. Content labelling materials (Art. 12 of the Labelling Measures and GB 45438-2025)

   Art. 12 of the Measures for Labelling AI-Generated Synthetic Content requires the provider, when completing algorithm filing, security assessment and similar procedures, to supply the labelling materials required by the Measures and to strengthen the sharing of labelling information in support of preventing and investigating related offences. Art. 11 requires labelling to conform to the applicable laws, administrative regulations, departmental rules and mandatory national standards — namely GB 45438-2025 on labelling methods for AI-generated synthetic content (issued 28 February 2025, effective 1 September 2025, in force, mandatory). The labelling statement in the pack should cover two lines. Explicit labelling: under Art. 4, an explicit label in the prescribed position for each modality, with the label preserved in files users download, copy or export — set out the position and presentation for text, audio, images, video and virtual scenes separately, with screenshots. Implicit labelling: under Art. 5, implicit labels in file metadata carrying the synthetic-content attribute, the provider’s name or code, a content identifier and other production information, conforming to the mandatory standard under Art. 11. Also describe the labelling clause in the service agreement (Art. 8), the retention of logs for at least six months for outputs without an explicit label (Art. 9), and, where the company also operates a dissemination platform, the verification and prompting duties under Art. 6. The materials must match the live implementation — a mismatch between what the filing describes and what the product does is the easiest gap for an inspection to find.

   Evidence to attach

   • · Position and presentation of the explicit label for each modality, with product screenshots
   • · Test records showing the label survives export, download and copying
   • · Field-level description and technical documentation of the implicit metadata labels
   • · Self-check matrix and gap list against GB 45438-2025
   • · The labelling clause in the service agreement, verbatim
   • · Log-retention configuration for unlabelled outputs (at least six months) and retention evidence
   • · Where operating a dissemination platform: the verification, prompting and provenance write-back implementation
   • · Reconciliation between the filed materials and the live implementation

   Common pitfalls

   • · A watermark on the page only, with the label lost once the user exports the file;
   • · Implicit metadata fields that do not follow the encoding required by the mandatory standard;
   • · A complete labelling scheme described in the filing but only partly implemented in the product;
   • · Logs for unlabelled outputs not retained, or retained for less than six months;
   • · Doing the generation side only, with no verification or prompting on the dissemination side.

7. 7. 7. Service agreement, usage boundaries and minor-protection materials

   Art. 9 of the Interim Measures makes the provider responsible as a producer of network information content, requires it to perform network information security duties, and, where personal information is involved, makes it a personal information processor; it must also conclude a service agreement with registered users clarifying the rights and obligations of both sides. Art. 10 requires the provider to specify and publish the population, settings and uses its service is intended for, to guide users to understand generative AI rationally and use it lawfully, and to take effective measures to prevent minors from over-relying on or becoming addicted to the service. Art. 11 requires protection of users’ input information and usage records: no collection of unnecessary personal information, no unlawful retention of input information and usage records that can identify the user, no unlawful provision of them to others, and prompt handling of requests to access, copy, correct, supplement or delete personal information. The pack should carry: the full service agreement (rights and obligations, prohibited uses, intellectual property, limitation of liability, dispute resolution); the published statement of intended population, settings and uses; the anti-addiction measures for minors (time prompts, content tiering, guardian tools); and the protection statement for input information and usage records (what is collected, retention, access control, and the commitment and technical controls against unnecessary use). Attach too the systems and registers for handling unlawful content, model optimisation and reporting under Arts. 14 and 15, and the complaint and reporting mechanism.

   Evidence to attach

   • · The full service agreement and records of user acceptance (version and effective date)
   • · Published statement of intended population, settings and uses, with screenshots of where it appears
   • · Evidence of minor identification and anti-addiction measures
   • · Collection scope, retention period and access-control configuration for input information and usage records
   • · Process and register for access, copy, correction, supplementation and deletion requests
   • · Closed-loop register for detecting, disposing of, retraining against and reporting unlawful content (Art. 14)
   • · Complaint and reporting entry point and its outcome register (Art. 15)

   Common pitfalls

   • · A service agreement lifted from a generic app template, silent on the boundaries of generated-content use and how responsibility is allocated;
   • · The intended population, settings and uses buried in a help centre rather than published prominently;
   • · Anti-addiction reduced to "please use responsibly", with no technical measure behind it;
   • · User input retained indefinitely by default and used for training, without this being clear in the agreement and privacy policy and with no way to switch it off;
   • · A disposal register recording deletions only, with nothing on the retraining and reporting Art. 14 requires.

8. 8. 8. Publishing the filing number and external consistency

   Art. 26 requires a provider that has completed filing to display its filing number prominently on the websites and applications through which it offers the service, with a link to the published information. That is a standing duty rather than a one-off, so build it into the release process: every external entry point — corporate site, web app, iOS and Android apps, mini-programs, open-platform documentation — carries the filing number and the link, and they are updated on redesigns, domain changes and new surfaces. Keep external statements consistent too: the published content in the filing system, the algorithm description inside the product, the automated-decision disclosure in the privacy policy, and marketing claims about model capability should not contradict one another. Marketing deserves particular care — a wide gap between publicly claimed capability and the algorithm description in the filing risks both an inaccurate-filing finding and problems under advertising and consumer protection rules. Run a quarterly consistency check led by legal, with product and marketing taking part.

   Evidence to attach

   • · Screenshots of the filing number and link at each service entry point, mobile included
   • · A release-gate checklist item for displaying the filing number
   • · Consistency matrix across the four external artefacts (filing publication, in-product description, privacy policy, marketing)
   • · Quarterly consistency check records and remediation items
   • · Records of updates made on domain, surface or brand changes

   Common pitfalls

   • · The filing number in the website footer only, absent from the app and mini-program;
   • · A dead filing number or link after a domain change or redesign;
   • · Marketing claiming capabilities well beyond the algorithm description in the filing;
   • · The privacy policy’s automated-decision disclosure contradicting the in-product algorithm description.

9. 9. 9. Amendment, cancellation and re-assessment for new products, applications and functions

   Filing is not a one-off. Plan three follow-on paths in advance. Amendment: where filed information changes — service form, application field, algorithm type, published content — an amendment filing is required, so write the triggers as a monitorable list and hook it into the product change process. Cancellation: when a service is terminated, a cancellation filing is required; Art. 17 of the Interim Measures expressly covers amendment and cancellation, and the Algorithmic Recommendation Provisions also address failure to cancel on termination. Security assessment for new products, applications and functions: Art. 20 of the Provisions on the Management of Deep Synthesis in Internet Information Services requires a deep synthesis provider developing and launching new products, applications or functions with public-opinion attributes or social-mobilisation capability to carry out a security assessment under the applicable national rules; and Art. 3(1) and (2) of the Security Assessment Provisions likewise treat launching such a service or adding such a function, and material change from new technologies or applications, as situations requiring a self-initiated assessment, with Art. 7 requiring the report for those two situations to be submitted **before** launch or the addition of the function, while situations (3), (4) and (5) require submission within thirty working days of the situation arising. Write that timing difference into the release process: what must be done before launch cannot be retrofitted afterwards.

   Evidence to attach

   • · Amendment trigger list with owners, wired into the product change process
   • · Records and receipts for past amendment filings
   • · Determinations and pre-launch submission records for new products, applications and functions
   • · The compliance gate in the release process (no launch until filing or assessment is complete)
   • · Cancellation filing records on service termination
   • · Submission channel and receipts for the security assessment report

   Common pitfalls

   • · Treating a "submit before launch" situation as a "within thirty working days" one, and getting the timing wrong;
   • · Adding a major function — extending from text to image or video generation — without a fresh security assessment;
   • · A change of algorithm type or application field with no amendment filing;
   • · No cancellation filing after a service is retired, leaving a dangling record;
   • · No compliance gate in the release process, so engineering does not know filing is a precondition.

10. 10. 10. Registers, consistency checks and inspection readiness

    After the filing is granted, what actually determines risk is day-to-day record-keeping. Maintain six registers with named owners: the filing register (number, filed content, amendment history, published link); the security assessment register (round, triggering situation, report version, submission receipt, remediation closure); the content-safety register (detection, disposal and reporting of unlawful and harmful information); the complaints register (intake time, handling duration, outcome, follow-up); the labelling register (implementation per modality, version changes, logs for unlabelled outputs); and the algorithm review register (rounds and conclusions of the Art. 8 periodic review, assessment and verification). Prepare an inspection pack as well: the latest summaries from those registers, the key policy texts, appointments and rotas, and system configuration screenshots, gathered under one index and refreshed quarterly. Art. 8 of the Security Assessment Provisions has cyberspace authorities and public security organs conduct a documentary review of the report, ordering a fresh assessment within a set period where content or items are missing or the method is plainly inappropriate, and allowing them to require supplementary explanation where content is unclear; Arts. 9 and 10 further provide for on-site inspection and expert review. The registers therefore need to support being spot-checked at any time, rather than being assembled in a hurry.

    Evidence to attach

    • · Current version of each of the six registers and the list of owners
    • · Inspection-pack index and the date it was last refreshed
    • · History of supplementary explanations provided after documentary review, where it occurred
    • · On-site inspection records and the remediation response, where it occurred
    • · Records of internal spot-check drills

    Common pitfalls

    • · Registers back-filled just before an inspection, with timestamps that do not match actual operations;
    • · A register orphaned when its owner leaves, leaving months of gaps;
    • · A complaints register counting volume but not handling time or outcome;
    • · Redoing an assessment by the same method after being ordered to reassess, so the underlying issue remains;
    • · An inspection pack spread across departments and impossible to produce promptly on site.