Using a third-party model does not, by itself, discharge an application operator’s safety assessment obligations under China’s generative AI rules. An operator may be required to assess its service even if it did not train the underlying model and cannot change its parameters. The relevant assessment must address how the application actually operates, including the models it calls, the users it serves and the controls applied to model outputs.

An enforcement notice published by the Cyberspace Administration of China (CAC) on 15 September 2026 illustrates the issue. According to the notice, a technology company in Jiangsu operated two websites offering conversational and question-answering services by accessing multiple large models through an “API relay platform”. The company failed to conduct the required safety assessment. It was ordered to rectify the breach and take strict action against those responsible, and received an administrative warning. The notice does not specify when the conduct occurred or when the enforcement action was taken.^[1]

The notice does not disclose the company’s full technical architecture or indicate whether it relied on limited technical capabilities in its defence. It nevertheless provides a useful starting point for examining what an application operator must assess, how upstream documentation can support that assessment and how technical limitations may affect compliance and administrative liability.

The assessment obligation follows the service provided

The Interim Measures for the Management of Generative Artificial Intelligence Services (Interim Measures) expressly include entities providing services through application programming interfaces within the definition of a service provider. Their scope, however, is tied to the provision of generative AI services to the public in China. Article 17 further requires safety assessments, in accordance with applicable rules, for services with public opinion attributes or the capacity for social mobilisation. These are separate questions: whether a business uses an API, whether it is a service provider and whether its service triggers the assessment requirement.^[2]

A business that adapts an interface to a customer’s specifications performs a different role from one that combines models and sells API access, or operates a question-answering product for end users. Describing a service as an “API relay” does not determine its regulatory treatment. Decisions about model selection, functionality, user access and routing rules help establish the operator’s role. Conversely, the absence of an end-user interface, or the fact that customers are businesses, is not sufficient on its own to establish an exemption.

Consider a hypothetical operator, Company A, which runs an AI question-answering website. The website normally calls Model A but automatically switches to Model B if Model A fails. Company A also applies its own content filters. Assume that the website falls within the applicable safety assessment requirements. The assessment would then need to address both normal operation and the fallback arrangement. Model B remains part of the application’s intended operating configuration even if it is used only during an outage.

The Provisions on Safety Assessment of Internet Information Services with Public Opinion Attributes or Social Mobilisation Capacity (Safety Assessment Provisions) allow providers to conduct the assessment themselves or engage a third-party organisation. The assessment covers safety management measures and the effectiveness of risk controls. Even without access to model parameters, Company A must therefore explain how it operates the service and manages the associated risks, and provide evidence supporting those conclusions.^[3]

An upstream model’s filing status is relevant, but does not establish that the downstream application has met all applicable requirements. CAC announcements on generative AI service filings state that applications or functions directly accessing the capabilities of filed models through APIs or similar means are subject to registration with local cyberspace authorities. This provides a route for the applications concerned; it does not establish that registration alone is sufficient for every relay or aggregation business. Model filing, application registration and safety assessment must be considered separately.^[4]

Upstream documentation must support the application assessment

The practical task is to identify which conclusions the available evidence supports and which gaps remain. Company A controls the switching conditions, API configuration and its own filtering rules. It should be able to explain whether switching occurs only on failure, which requests are passed to Model B and whether Model B’s outputs undergo the same checks. These are matters of application design that can be examined without full access to the upstream technology.

Application testing can provide further evidence. By simulating a Model A outage, Company A can check whether requests are routed to Model B as intended, whether the fallback bypasses existing filters and whether the system detects and handles unexpected outputs. Such testing supports conclusions about a particular configuration within the scope of the tests. A limited sample cannot establish that every possible input, or every subsequent version, is free of risk.

Other matters require upstream confirmation. Safety documentation covering only Model A, or a product version different from the API actually used, cannot establish how Model B performs through the relevant interface. Where the assessment relies on upstream safeguards, Company A needs to establish whether those safeguards apply to the API it purchases, whether their operation depends on configuration and whether version changes affect the assessment. The objective is to obtain information needed for specific assessment questions, rather than unrestricted access to source code, parameters or all internal records.

In our view, each information gap should be addressed according to its effect on the assessment. Company A should complete its own records where those records can establish the relevant facts, explain the methodology and limitations of application tests, and obtain upstream confirmation where necessary. If missing information prevents a required conclusion from being reached, that limitation should be recorded expressly. A general assurance that a product is “compliant” cannot fill a specific evidential gap.

Unresolved assessment issues must inform launch decisions

The Safety Assessment Provisions require assessment reports to be submitted before launch in specified circumstances, including the launch of relevant services or the addition of relevant functions. They also require identified safety risks to be addressed promptly. The assessment therefore bears directly on whether the service is ready for launch under the applicable requirements.^[5]

If missing information prevents Company A from completing the necessary assessment of Model B, it could consider disabling automatic fallback and completing the assessment for a configuration using Model A alone. Whether this is sufficient depends on whether the revised service satisfies the applicable requirements. Disabling a feature is not, in itself, evidence of compliance. If fallback is subsequently restored, Company A would need to consider whether the existing assessment covers that configuration and whether further procedures are triggered.

An inability to modify a model is different from an inability to organise an assessment. Company A may be unable to remedy a defect within Model B, but it can decide whether to include that model in its product and on what terms. The assessment should inform those decisions. Upstream limitations that the operator cannot resolve should be reflected in the scope and conditions of the service it makes available.

Measures taken during operation serve a separate purpose. If Company A discovers problems with fallback after launch, promptly disabling Model B may help contain the risk. That action does not substitute for an assessment that should have been undertaken earlier. Equally, an initial assessment cannot indefinitely cover later changes. Whether changes to a model, functionality or configuration require further assessment depends on their implications for the nature and risks of the service.

Technical limitations must be linked to the alleged breach

The relevance of technical limitations to administrative liability depends on the specific breach alleged. Under Article 33, paragraph 2 of the PRC Administrative Penalty Law, no administrative penalty is to be imposed where a party adduces sufficient evidence that it was not at fault, unless a law or administrative regulation provides otherwise. Establishing non-compliance does not dispense with the need to examine the statutory conditions for a penalty.^[6]

For an alleged failure to conduct a required safety assessment, evidence that Company A could not modify model parameters would not, on its own, adequately explain why it did not arrange the assessment. Supplier assurances, requests for information, test records and launch approval materials may be relevant to the fault analysis, but their evidential value depends on what they show. Did Company A apply documentation for Model A to Model B without verification? Once it identified a gap, did it leave fallback enabled, obtain further support or restrict the service? These facts are more informative than a general assertion of dependence on a third party.

Neither a procurement contract nor a supplier assurance should be treated in advance as establishing an exemption from liability. Equally, the occurrence of a problem does not automatically deprive all evidence of compliance efforts of its value. Fault, and any grounds for imposing no penalty or a lighter or mitigated penalty, must be assessed on the facts and under the applicable provisions.^[7]

Procurement terms can support the assessment by addressing API and version specifications, change notifications, testing assistance and remediation support. For Company A, those terms should help it verify the services actually provided by Models A and B and adjust its routing arrangements if necessary support is unavailable. Simply allocating “all compliance responsibility” to the supplier does not resolve gaps in information or assessment capability.

The assessment’s conclusions should match the service configuration proposed for launch or actually in operation. An operator should be able to explain why each model invocation path forms part of its service and whether the evidence and controls supporting that decision are sufficient. Unresolved technical limitations belong in the assessment and launch decision, rather than being raised only after a risk materialises as an explanation for non-compliance.

Sources

Linked sources are in Chinese. English titles and terminology are used for reference.

[1] Cyberspace Administration of China, Notice on Recent Illustrative Enforcement Cases in Cybersecurity, Data Security and Personal Information Protection, 15 September 2026, Case 10.

[2] Interim Measures for the Management of Generative Artificial Intelligence Services, Articles 2, 17 and 22.

[3] Provisions on Safety Assessment of Internet Information Services with Public Opinion Attributes or Social Mobilisation Capacity, Articles 3–5.

[4] Cyberspace Administration of China, Announcement on Generative Artificial Intelligence Service Filings for March–April 2026, 13 May 2026.

[5] Safety Assessment Provisions, Articles 3, 6 and 7.

[6] Administrative Penalty Law of the People’s Republic of China, Article 33, paragraph 2.

[7] Administrative Penalty Law of the People’s Republic of China, Articles 32 and 33.