Writing the Security Assessment Report for Large-Model Filing: Eight Chapters and an Evidence Chain

The security assessment report for large-model filing is often treated as a longer version of the algorithm self-assessment: download the template, fill every cell, attach a few architecture diagrams, submit. The return notice frequently consists of a single sentence — the risk description does not match the model’s actual capability.

The problem is not that too little was written, but that what was written does not correspond to how the system runs. The reviewer must establish three things: what the model can do, which risks those capabilities carry, and what evidence shows each risk is already controlled. The report should be organised around those three questions, not around the chapter order of a template.

How it differs from the algorithm security self-assessment

The two reports are easily confused because both are called security assessments and both are issued by the filing entity. The difference lies in coverage and evidential requirements.

A sound report should, after reading, answer: can this model generate unlawful content, can it disclose personal information in its training data, can it be bypassed by prompt injection, and how quickly can an incident be handled. If it cannot, the report remains at the level of mechanism description.

Three preparations before drafting

The quality of the report is seven-tenths determined by what is in hand before drafting begins.

One, the capability list. Set out what the model can and cannot do, and where its boundaries lie: modalities supported, context length, whether tool calling and web access are available, whether multi-turn and role-play are supported, whether fine-tuned versions exist. The capability list determines the risk list: a model with web access must be assessed for injection of external content; one that executes code, for generation of malicious code; one that only summarises text faces a far narrower risk surface.

Two, test records. The test question set, sample sources, criteria, test environment, result statistics and failed cases. Testing is not a formality; it must leave original records capable of recomputation. Questions should be grouped by scenario, each with positive and bypass samples, covering multi-turn inducement, prompt injection and jailbreak templates.

Three, operational data. Interception logs, manual review tickets, user complaints and incident handling records. Anyone can write a policy; only operational data shows that a mechanism is running. Logs from the last three months persuade more than a flawless compilation of policies.

With these three in place, the eight chapters merely organise the material into a readable structure.

The eight chapters

Chapter 1, overview of the model and service system. State the model’s origin (self-developed, fine-tuned on an open-source foundation, or API wrapper), parameter scale, training and inference architecture, service form (web, app, API, on-premises), users and scenarios. The point is to define the service boundary: public-facing or sector-specific, and whether it carries public-opinion attributes or social mobilisation capability. This chapter determines the scope of all subsequent risk.

Chapter 2, corpus sources and lawfulness. Classify by source: self-collected, purchased, open-source datasets, user-generated and synthetic. For each, state the acquisition method, authorisation documents, cleaning and filtering process, labelling rules, and the proportion of unlawful or harmful information before and after filtering together with the detection method. The common failing is to write ‘filtered’ without the proportions, detection method or sampling records. A broken authorisation chain at the second-tier source is the typical ground of return here.

Chapter 3, security of the training and fine-tuning process. Describe the training environment, data isolation, permission control, training logs, model version management, and the source and review of fine-tuning data. The point is to show that the process is traceable: which version used which batch of data, who approved it, where the artefacts are stored. Where third-party or overseas computing power is used, state whether data leaves China.

Chapter 4, security of output content. Describe the interception mechanism, review workflow, labelling method and the handling loop. Interception has three layers — keyword library, classification model and manual review — and each layer’s trigger conditions and handling of false positives must be stated. Labelling follows the Measures for Labelling AI-Generated Synthetic Content, distinguishing explicit from implicit labels and stating where and in what form they appear. The handling loop covers detection, interception, review, appeal and post-incident review.

Chapter 5, resistance to attack and adversarial testing. Describe the types of adversarial testing conducted, the number of samples, the success rate and the defensive measures. At a minimum cover prompt injection, jailbreak, multi-turn inducement, context poisoning and model extraction. The point is to give results, not to assert that defences exist. Items that failed testing require a remediation plan and a retest date.

Chapter 6, user rights and personal information protection. Describe the implementation of notice and consent, the processing and retention of user input, the handling of personal information in training data, the response mechanism for access, copying and deletion, and protections for minors. The point is consistency with the privacy policy and user agreement: three documents describing the same chain.

Chapter 7, risk identification, grading and treatment. This is the core chapter. List risks by model capability and scenario, and for each state likelihood, impact, affected object, risk level, treatment measure, owner and completion deadline. A risk level must map onto a treatment action; marking something ‘high risk’ without saying how it is handled is not an assessment.

Chapter 8, emergency response and continuous monitoring. Describe the contingency plan, incident grading, response time limits, reporting process, drill records and monitoring indicators. The point is executability: who does what and by when, rather than ‘will be handled promptly’. For continuous monitoring, state indicators and thresholds, such as interception rate, false-positive rate, complaint rate and early-warning lines for incident numbers.

How to arrange the evidence chain

The report persuades through its evidence chain, not its length. It is advisable to close each chapter with an evidence index in a uniform format.

The purpose of the table is to let the reviewer judge within ten minutes whether a report is credible. Without an index, evidence is scattered across dozens of pages of annexes, and the cost of reading pushes the judgment towards ‘insufficient materials’.

Five frequent grounds of return

One, risk items do not match model capability. The report states that the model has no web access while the product supports retrieval; or states text-only while image generation is live. A capability list out of step with the product version is the commonest hard defect.

Two, the interception rate has no data behind it. The report claims 99% while the annexes contain no test set, no statistical basis and no log export. A figure that cannot be recomputed is treated as not provided.

Three, the test set does not cover high-risk scenarios. The questions are general knowledge questions with no samples for medical, financial, minors or politically sensitive scenarios, and no bypass samples. Insufficient coverage amounts to no testing.

Four, the corpus authorisation chain is broken. Purchased data comes with only the immediately preceding contract, without tracing the scope authorised by the original rights holder; open-source datasets are named without the licence text or a commercial-use judgment.

Five, the report is inconsistent with the contract and privacy policy. The report says user input is not used for training while the user agreement says it may be used to improve the service; the report says data is stored in China while the privacy policy says it may be transferred to overseas affiliates. Three documents contradicting one another will each be questioned separately.

Division of work and timing

No single legal team can write the report. A sensible division runs three workstreams in parallel:

A typical project takes four to six weeks: the first week to collect material and confirm the capability list; the second and third to complete testing and data statistics; the fourth and fifth to draft and cross-check; the sixth to consolidate and seal. More complex models with more scenarios take correspondingly longer.

Where algorithm filing has already been completed, shared material can be reused directly and the report can concentrate on the corpus, training and output chain specific to large models, without rewriting from scratch.

Relationship with the filing document list

The security assessment report is one of five specialised documents, the others being the model service agreement, corpus labelling rules, the interception keyword list and the assessment test question set. The five are cross-referenced: the report cites the library version, the test set and the labelling rules, so a change to any one requires a corresponding update to the report.

The full list of documents for both types of filing, and the order in which to prepare them, is set out in What Documents Large-Model Filing Requires; the classification between the two filings is in What Is the Difference Between Algorithm Filing and Large-Model Filing; continuing obligations after filing are in Ongoing Obligations After Algorithm Filing.

The technical source of the requirements is the national standard GB/T 45654—2025, Cybersecurity Technology — Basic Security Requirements for Generative Artificial Intelligence Services, in force from 1 November 2025, which turns the principles of the Interim Measures into testable provisions; see the standard explained. Corpus filtering, output interception and testing requirements in the report should follow the latest text of that standard.

Our service scope is set out under algorithm filing and AI legal services.

This article is based on the Interim Measures for the Administration of Generative Artificial Intelligence Services, GB/T 45654—2025 and publicly available filing practice. It is for reference only and does not constitute legal advice. Specific document requirements should follow the latest guidance of the competent provincial cyberspace administration and the filing system.