Verification Checklist
- ✓Has the system behind your public-facing service ever gone through level protection tiering and filing, or has that process never happened at all
- ✓Have you been treating "generative AI service filing done" or "ICP filing done" as if it covered level protection assessment too, and so skipped this separate item
- ✓Was your system's specific tier determined by your own team's guess, or verified with a qualified assessment institution or the local public security cybersecurity authority
- ✓If your product handles real-name user data, payment data, or user data at scale, have you evaluated whether that pushes your system's required tier higher
- ✓Has calling an LLM API been treated as a blanket "doesn't affect level protection" or "automatically bumps the tier" conclusion, rather than judged against your actual business scenario
1. The pattern: filing is done — is level protection assessment done too?
A previous article on this site covered how developers calling DeepSeek, Doubao, or similar LLM APIs to build public-facing products often conflate ICP filing with generative AI service filing — two things overseen by different ministries. This piece covers a third compliance duty that regularly gets missed: the network security level protection assessment, commonly shortened to "Dengbao" or level protection assessment in industry usage. Unlike the first two, its legal basis is China's Cybersecurity Law, and it has no necessary connection to whether your product is an AI service at all — regardless of whether a system calls a large model, if the public-facing information system reaches a sufficient level of importance, its operator is required by law to complete tiering, filing, and assessment. The first common mistake is assuming that once the two "filings" are done, level protection is automatically handled too — it is in fact a fully independent third regime that has to be initiated and completed on its own.
2. What the assessment actually evaluates: the system's own security controls, not generated content
A boundary that's easy to get backwards needs clarifying first. Generative AI service filing is concerned with the algorithm's mechanism, training data provenance, and whether generated content itself is safe and compliant — a "content-side" question overseen by cyberspace administration authorities. Network security level protection assessment, on the other hand, is concerned with the security protection capability of the information system carrying that service — network architecture, host security, application security, data security, and whether the relevant technical and management measures meet the required standard — largely unrelated to whether the AI-generated content itself is compliant, and it is overseen by public security cybersecurity authorities, with the actual assessment carried out by qualified third-party assessment institutions. In other words, even if your AI-generated content is fully compliant and generative AI filing is successfully completed, if the servers, databases, and application systems carrying that service haven't been tiered, filed, and assessed per level protection requirements, the system remains non-compliant on this separate dimension — the two regimes are simply not evaluating the same layer of the stack.
3. How tiers get set: no blanket number, defer to official assessment guidance
On exactly which tier a given system should be assigned, it needs to be stated plainly: the specific tiering criteria involve considerable technical detail, and the industry, the system's business importance, the scale of users served, and the sensitivity of the data involved can all affect the outcome. Publicly available material describes the tiering framework in principle, but no single article — this one included — can responsibly give a blanket answer for which tier a specific system should carry. In practice, tiering is typically first proposed by the system's operator per relevant standards, then verified and filed with a qualified assessment institution or the local public security cybersecurity authority, with the authority's reviewed and accepted result being final. If you're unsure what tier your system should carry, the direct path is to contact your local public security cybersecurity authority or engage a qualified level protection assessment institution for a preliminary evaluation, rather than copying a tier from an unrelated article or another company's system.
4. Does calling an LLM API raise the tier requirement? It depends on the actual business scenario
This question comes up often, and it likewise doesn't have a single universal answer. Calling a DeepSeek or Qwen API by itself simply adds an outbound request interface and a data flow to your system — that alone doesn't inherently force the tier "up," nor does it mean "since we call an API, level protection doesn't apply to us." What actually drives the tiering conclusion is the overall business importance and data sensitivity carried by the system as a whole — whether it processes real-name user data at scale, whether it involves payment or financial data, whether it's designated a key protected object by a relevant industry authority. These factors already shape tiering on their own, and calling an LLM API could only indirectly affect the conclusion if it genuinely changes the type of data processed or the business importance of the system. The honest answer is that this needs to be judged by a qualified assessment institution or public security authority against your system's actual business scenario — there is no universally applicable rule that "calling an AI API automatically bumps the tier" or "calling an AI API means it doesn't apply," and this piece does not make a blanket claim either way.
5. The two opposite mistakes developers most commonly make
Building on the previous sections, the two most common mistakes in practice run in exactly opposite directions. The first is assuming "generative AI service filing is done, so level protection doesn't need attention" — because both get loosely called "filing," it's easy to default to treating them as two steps of the same thing, when in fact their legal basis, overseeing authority, and evaluation target are entirely different, and completing one does nothing to satisfy the other. The second runs the other way: assuming "level protection assessment is done, so generative AI service filing doesn't need attention" — a passing level protection assessment certifies that the system's own security controls meet the required standard, and says nothing about whether your AI service carries public-opinion attributes or social mobilization capability, or whether it needs its own algorithm filing on the content side; a system that passed level protection assessment can still be running a generative AI service that hasn't completed the filing it needs. Put alongside ICP filing, algorithm recommendation filing, and generative AI service filing covered in an earlier article, level protection assessment rounds out the four compliance duties developers most commonly confuse — independent of each other, none substituting for another, each needing to be verified and completed on its own.
6. Bottom line
Network security level protection assessment is a general information-system security compliance duty required under China's Cybersecurity Law, with no necessary connection to whether your public-facing service is an AI product, and it is not automatically waived by completing generative AI service filing or ICP filing. It evaluates the security protection capability of the information system carrying the service; the specific tier needs to be judged against business importance and data sensitivity, per official assessment guidance and the public security authority's verified result, and whether calling an LLM API affects tiering likewise needs a case-by-case judgment rather than a blanket answer. The first thing to check is whether your own system has ever gone through level protection tiering and filing at all — not to assume that filing one thing means everything is filed.