China PIPL AI Risk Assessment: Articles 55 and 56 in Practice

A Shanghai benefits team plans to let an LLM summarize employee medical claims. The first prompt will contain sensitive personal information. A foreign model provider may receive it as an entrusted party and as an overseas recipient. Article 55 of China's Personal Information Protection Law (PIPL) requires the assessment before that processing starts.

I would stop the launch review at the request trace. If the team cannot show who assembles the context, which endpoint receives it, and what happens to the output, a five-color risk matrix adds decoration rather than evidence.

TL;DR

• PIPL Article 55 requires an advance impact assessment for five trigger classes, including sensitive personal information and automated decision-making.
• Entrusted processing, disclosure, overseas provision, and other processing with a major influence on individuals also trigger the duty.
• Article 56 tests the processing purpose and method, effects and security risks, and whether protective measures match the risk.
• Preserve the assessment report and the record of the handling situation for at least three years, then connect each safeguard to operating evidence.

Article 55 is a trigger test before processing

The official National People's Congress text of the PIPL says the personal information handler shall conduct a personal information protection impact assessment in advance and record the handling situation when an Article 55 circumstance is present. The sequence matters because approval follows a documented assessment of the proposed operation.

Article 55 names five trigger classes. They cover sensitive personal information and automated decision-making. The list also reaches entrusted processing, provision to another handler, or public disclosure. Overseas provision has its own trigger. A catch-all covers other personal information processing with a major influence on individuals.

Start one scoping record per AI use case. Name the handler and the people affected. Record the decision or service involved and the personal information entering the context. Add the model route, provider role, recipient location, and downstream use of the output. Mark every Article 55 trigger separately because one request can activate several.

Article 56 defines the assessment substance

Article 56 sets the substance of the analysis. First, test whether the processing purpose and method are lawful, legitimate, and necessary. For an LLM workflow, describe the task in operational terms. "Improve HR" gives reviewers little to test. "Summarize a medical reimbursement claim for the assigned benefits specialist" identifies the purpose and exposes the data minimum.

Then assess the influence on individuals' rights and interests alongside the security risks. That work should follow the data path. Consider an inaccurate summary entering an employee record. Examine disclosure to an unintended model endpoint and access by an over-broad role. Include provider retention and onward handling when those facts apply.

The final statutory test asks whether the protective measures are lawful and effective, with strength suited to the degree of risk. The assessment should link each risk to a control owner and test. It should also identify residual risk and the person accepting it. The AI DPIA guide gives a broader assessment structure, while Article 56 supplies the PIPL decision criteria.

Sensitive personal information raises the design bar

Article 28 defines sensitive personal information by the harm that leakage or unlawful use can cause. Its examples include biometrics and specific identity information. Medical health and financial accounts appear as well, together with location tracking and information about minors under 14. Processing requires a specific purpose, sufficient necessity, and strict protective measures.

That changes the AI assessment before a developer tests the first production prompt. Identify each sensitive field and explain its role in the task. Reduce the context to the fields needed for that purpose. Record Article 29 separate consent where consent is the applicable basis, plus the enhanced notice required by Article 30. Children under 14 require the parent or guardian consent and special handling rules described in Article 31.

Put the evidence on one page. Draw the authenticated caller at the left in a blue box, the application in the middle, and the model endpoint on the right. Circle every sensitive field in red and mark retained copies underneath. The AI data classification guide supplies a practical vocabulary for that request-level view.

Automated decision-making needs a decision record

Article 55 makes the use of personal information for automated decision-making an assessment trigger. Article 73 defines that activity as automatic analysis or evaluation of personal behavior and characteristics, followed by decision-making. Article 24 adds transparency and fairness requirements. It also addresses unreasonable differential treatment in transaction terms and rights tied to decisions with a major effect on an individual's rights and interests.

The assessment should identify the point where an LLM output influences an outcome about a person. Record the input sources and model configuration. Preserve the output and the policy applied, with the authorizing identity and timestamp. Add the explanation route and any refusal or human-handling path the use case requires.

A human approval step deserves scrutiny. Name the reviewer and the information available to that person. Record the time and authority to change the outcome. My view is that a click labeled "approve" provides no meaningful risk reduction when the reviewer sees only the model's recommendation.

Entrusted processing and disclosure need separate analysis

Article 55 covers entrusted processing, provision to another personal information handler, and public disclosure. Those relationships create different obligations, so the assessment should classify the model provider's actual role rather than rely on the word "vendor."

For entrusted processing, Article 21 requires the handler and entrusted party to agree the purpose and period. The agreement also covers the processing method and personal information categories, plus protective measures and both parties' rights and duties. The handler supervises the entrusted activity. The assessment should therefore include provider retention, sub-entrustment, deletion or return, access controls, and evidence access.

Provision to another handler invokes the Article 23 notice and separate-consent analysis. Public disclosure invokes Article 25. Map each data movement to the correct relationship, then test contractual wording against the provider's technical behavior. The AI consent enforcement guide shows how a recorded permission can become a request-time policy input.

Cross-border transfers create a parallel assessment track

Providing personal information outside mainland China is an express Article 55 trigger. The assessment should identify the receiving entity and actual processing location for each route. It should capture the information categories and purpose, along with retention, onward recipients, and the way individuals can exercise their rights.

The transfer also needs the applicable Chapter III route. Its Article 38 provides the legal mechanisms. Separate notice about the overseas recipient and separate consent come from Article 39. For critical information infrastructure operators and handlers reaching the prescribed quantity, Article 40 adds localization and security-assessment duties. Later CAC rules affect which transfer mechanism applies, but they leave the Article 55 assessment trigger in place.

Dynamic model routing makes a vendor inventory too coarse. Preserve the endpoint and jurisdiction on each request, then connect that record to the approved assessment and transfer mechanism. The AI data residency controls guide covers the enforcement pattern at that boundary.

The catch-all reaches processing with major influence

Article 55 closes with other personal information processing activities that have a major influence on individuals. Treat this as a reasoned risk finding rather than a label attached only after a complaint. The assessment should examine the sensitivity and scale of the information, the people affected, the decision consequences, and the ability to reverse harm.

An internal LLM search feature can sit outside the automated-decision trigger and still raise this catch-all. A broad employee index may reveal medical leave or disciplinary material to an unintended audience. A support summarizer may expose identity documents through an over-broad retrieval step. The assessment records the mechanism and affected group, then states why the influence crosses or stays below the threshold.

Keep the rationale with the approved scope and evidence. Article 56 requires analysis of effects on rights and security risks, which gives the handler a structured basis for that conclusion. Legal owners should approve close calls and record the facts used.

Retention covers the report and the handling record

Article 56 requires preservation for at least three years of the impact assessment report and the record of the handling situation. The Stanford DigiChina English translation renders these as the assessment report and handling status records. The Chinese statute controls, and the translation helps English-speaking teams trace the structure.

Keep the approved report with its scope and version. Preserve the decision, owners, tests, and residual-risk acceptance. Link those materials to the deployed configuration and change record. For routed AI traffic, retain request-level evidence showing which identity used which model under which policy, subject to the organization's lawful retention design.

A three-year archive of the original PDF proves the assessment occurred. It says little about a provider change made six months later. Define reassessment triggers for a new purpose or data category, a different model region, changed provider retention, or a new downstream decision. Record the trigger in change control and update the assessment before the changed processing begins.

DeepInspect

DeepInspect can enforce and evidence selected safeguards on HTTP AI traffic deliberately routed between authenticated users or agents and LLM endpoints. It evaluates application-supplied identity and role with prompt classification, destination, and model authorization before forwarding the request. The resulting per-decision record can show how an approved safeguard handled a specific request under a specific policy version.

Its boundary is explicit. DeepInspect contributes evidence for routed HTTP requests and responses. The handler retains legal scoping, purpose and necessity analysis, consent, provider-role classification, individual-rights handling, and residual-risk acceptance. Training-data provenance and model development sit elsewhere. Local inference, browser sessions, direct calls that bypass the proxy, endpoint compromise, and provider-internal processing also fall outside its visibility.

Book a technical deep dive at deepinspect.ai.