← Blog

China PIPL LLM Requirements: A Current Enterprise Guide

Parminder Singh
Parminder Singh··9 min read
Summarize with AI

China's Personal Information Protection Law applies to LLM workflows whenever prompts, retrieved context, outputs, or operating records contain personal information. Enterprises must establish an Article 13 basis, give the required notices, minimize the data, handle sensitive information under stricter rules, and meet automated-decision and cross-border conditions. Provider duties depend on the actual relationship: an entrusted party follows the handler's instructions and assists with compliance, while an independent handler carries its own PIPL obligations.

Compliance & Regulationai-complianceai-governancecomplianceregulationllmpolicy-enforcement
China PIPL LLM Requirements: A Current Enterprise Guide

A Beijing recruiting team connects an LLM to candidate files. The prompt carries names and employment history. It also carries an interview transcript. Retrieval adds a medical accommodation note, while the model endpoint sits outside mainland China. One request now raises questions about lawful basis and notice, data minimization and sensitive information, the provider relationship and automated decisions, plus cross-border handling under China's Personal Information Protection Law (PIPL).

I would hold the launch until each question has an owner and a record. A generic approval for "AI use" tells the privacy team almost nothing about this request.

TL;DR

  • PIPL applies when prompts and retrieved context, plus outputs and related records, contain personal information. Article 13 requires a valid processing circumstance. Consent is one route, not the universal answer.
  • Articles 6 and 7 govern purpose, transparency, scope, and method; Article 17 governs notice. A broad context window conflicts with the smallest-scope rule when the task needs only a few fields.
  • Sensitive personal information invokes Articles 28 to 31. Automated decisions invoke Article 24, with transparency, fairness, explanation, and refusal rights in specified cases.
  • Enterprises must classify each provider's role. Entrusted processing and provision to another handler carry different duties. Overseas receipt adds records and notices, plus consent questions.

PIPL follows the personal information through the LLM workflow

The official National People's Congress text of the PIPL defines personal information broadly as electronically or otherwise recorded information relating to an identified or identifiable natural person, excluding anonymized information. Handling includes collection and storage; use and processing; transmission and provision; disclosure and deletion. The Stanford DigiChina English translation gives English-speaking teams a reader-accessible rendering, while the Chinese text controls.

That definition reaches more than the text typed into a chat box. Retrieved customer records can enter the context window. A response may contain an assessment about an employee. Request logs and evaluation datasets may preserve copies. Support tickets may do the same. Map each location before deciding which PIPL requirements apply.

Start with one dedicated use-case record. Name the enterprise personal information handler and affected people; the task and information categories; the model endpoint and output use; and the retention points. The PIPL compliance checklist gives the wider review sequence. This article concentrates on the requirements governing the LLM use itself.

Article 13 requires a basis tied to the actual purpose

Article 13 permits handling under specified circumstances. Consent is one legal route under Article 13. Others include necessity for concluding or performing a contract with the individual and legally conducted human-resources management. They also include statutory duties or obligations and public-health or emergency protection. Public-interest reporting and reasonable handling of lawfully disclosed information provide further routes. The correct route depends on the facts and purpose.

An enterprise should identify the Article 13 circumstance before production data enters an LLM. "Business improvement" is too loose. "Summarize a customer's warranty claim so the assigned caseworker can answer it" gives counsel and engineering a purpose they can test against the data and output.

Where consent supplies the basis, Article 14 requires a voluntary and explicit statement based on full knowledge. A change to the purpose or method requires consent again. A change to the personal-information categories does too. Article 15 adds a convenient withdrawal route. The application must carry the resulting permission state into the workflow; the model provider cannot infer it from prompt text.

Transparency and minimization shape the context window

Article 6 requires a clear and reasonable purpose, direct relation to that purpose, the method with the smallest influence on individual rights and interests, and collection limited to the smallest scope needed. Article 7 adds openness and transparency. Under Article 17, the handler generally gives clear notice before handling. The notice covers its identity and contact details; purpose and method; information categories and retention period; and the rights process.

Translate those duties into the retrieval design. Define which fields the application may fetch and which fields it may place in the prompt. Define how long each copy remains. Test the system with production-shaped records rather than assuming the retrieval layer will return only useful text.

Picture the review on a whiteboard. Put the authenticated caller in a blue rectangle at the left and draw the application as a black box in the center. Mark the model endpoint with a red border on the right. Write every personal-information field along the arrows. If the team cannot explain why the medical note crosses the red line, remove it before launch. My view is that buying a larger context window often makes PIPL minimization harder, because unused personal information becomes cheap to include and expensive to justify.

Sensitive personal information needs a stricter route

Article 28 covers personal information whose leakage or unlawful use can readily harm personal dignity or personal and property security. The statute names biometrics and religious belief; specially designated status and medical health; financial accounts and location tracking; and information about minors under 14. Handling requires a specific purpose and sufficient necessity. It also requires strict protective measures.

When consent applies, Article 29 requires separate consent for sensitive personal information. Article 30 generally adds notice of why the processing is necessary and its effect on individual rights and interests. Article 31 requires consent from a parent or other guardian for information about a child under 14 and calls for special handling rules.

For an LLM, classify retrieved context before transmission. Keep sensitive fields out of general-purpose prompt templates. Record the specific purpose and necessity, then connect the permission state and approved destination to the request policy. The AI consent enforcement guide explains how an application-supplied consent signal can become one input to a request-time decision without pretending that a proxy collected the consent.

Article 24 governs personal-information automated decisions

Article 24 applies when a handler uses personal information for automated decision-making. It requires transparency in the decision process and fairness and justice in the result. The handler must avoid unreasonable differential treatment in transaction conditions such as price. Personalized information delivery or commercial marketing also needs a non-personalized option or a convenient refusal method.

A decision with a major influence on an individual's rights and interests creates further rights. The individual may request an explanation and refuse a decision made solely through automated means. An LLM-generated recommendation can therefore require more than a model card when it influences hiring and credit, insurance and benefits, or access to a service.

Document where the output enters the decision. Preserve the relevant input and output; model route and policy version; and authorizing identity under the organization's lawful retention design. Record the explanation path and the person authorized to alter the result. The PIPL audit-evidence guide covers the artifacts a reviewer can test after deployment.

Enterprise and provider duties depend on the relationship

The enterprise usually determines why its staff or agents use an LLM and which records enter the request. As the personal information handler, it selects the Article 13 circumstance and provides required notices. It also applies minimization, handles individual rights, evaluates sensitive-information conditions, and determines the provider relationship. Article 55 requires an advance personal information protection impact assessment for sensitive-information handling and automated decision-making; entrusted processing or provision to another handler; overseas provision; and other handling with a major influence on individuals.

When the model provider acts as an entrusted person, Article 21 requires an agreement covering purpose and duration; method and information categories; safeguards; and both parties' rights and duties. The enterprise supervises the entrusted activity. The provider stays within the agreed purpose and method, and returns or deletes information when the arrangement ends. It obtains permission before further entrustment. Article 59 directly requires the entrusted person to take necessary security measures and assist the handler with PIPL obligations.

A provider deciding its own purposes may instead be another personal information handler. Article 23 then requires the originating handler to give the recipient details and obtain separate consent. The recipient stays within the disclosed purpose and method. It also stays within the disclosed categories unless it completes the required new-consent process. Contract labels should follow the operating facts.

Cross-border use adds Articles 38 to 40

An LLM request containing personal information becomes an overseas-provision issue when the recipient is outside mainland China. Article 38 requires an applicable transfer condition. This may be a Cyberspace Administration of China security assessment or personal information protection certification. It may instead be a standard contract or another route provided by law or the national cyberspace authority. Article 38 also requires necessary measures so the foreign recipient's handling reaches the PIPL protection standard.

Article 39 separately requires notice of the foreign recipient's identity and contact method; purpose and method; information categories; and the route for exercising rights. It also calls for separate consent. Article 40 adds domestic-storage and security-assessment requirements for critical information infrastructure operators and handlers reaching the quantities prescribed by the national cyberspace authority. Implementing rules determine which mechanism and exemptions apply to a particular transfer, so legal review needs the current route facts and volumes.

Inventory lists are too coarse for dynamic model routing. Record the endpoint and jurisdiction selected for the request, then compare that route with the approved transfer condition. The AI data residency controls guide shows the request-boundary pattern. Provider-side storage and support access, safety review and subprocessors, plus onward transfers belong in the same analysis.

Current LLM approval needs two connected records

The first record is the approved design. It identifies the Article 13 circumstance and notices; data minimum and sensitive-information conditions; provider role and automated-decision use; transfer route and retention; and the rights process. Article 55 determines when an advance assessment is mandatory, while Article 56 specifies its analysis and at least three-year preservation for the assessment report and handling-status record.

The second record shows operation. For each routed request, capture the authenticated identity or agent and relevant classification; destination and policy decision; and the correlation identifier. Preserve only the content and metadata justified by the organization's purpose and security analysis. Apply the organization's retention analysis as well. Link operating records to the approved use-case and policy version so a provider or routing change becomes visible.

Reapproval triggers should include a new purpose and an added data category; a foreign endpoint and altered provider retention; a subprocessor change; or a new consequential use of the output. A procurement renewal alone misses changes made between contract dates. The PIPL controls mapping connects the legal requirements to specific enforcement and evidence points.

DeepInspect

DeepInspect can enforce selected enterprise policies on HTTP AI traffic deliberately routed between authenticated users or agents and LLM endpoints. It evaluates application-supplied identity and role; consent or purpose signals; prompt classification and destination; and model authorization before forwarding a request. A per-decision record can connect that request to the policy version. It can also record the outcome.

The product boundary remains narrow and explicit. DeepInspect does not choose an Article 13 circumstance or draft notices. It does not collect consent, classify the provider's legal role, complete an Article 55 assessment, or select a cross-border mechanism. It contributes control and evidence for routed HTTP requests and responses. Provider-internal processing and training-data governance, local inference and browser use, plus direct calls that bypass the proxy remain outside its visibility.

Book a technical deep dive at deepinspect.ai.

Frequently asked questions

Does PIPL require consent for every enterprise LLM request?

Article 13 contains several permitted circumstances, and consent is one of them. An enterprise should select the circumstance that actually supports the stated purpose rather than assume a blanket consent rule. When processing relies on consent, Articles 14 and 15 govern its quality and renewal after specified changes. They also govern withdrawal. Separate consent arises in situations that include sensitive personal information and provision to another handler. It also arises for overseas provision. Legal owners should document how those rules interact for the use case.

Is the model provider always an entrusted person?

The operating facts determine the role. A provider processing only on the enterprise handler's documented instructions may be an entrusted person under Article 21. A provider choosing independent purposes or methods may act as another handler for some processing. One service can also involve different roles for the enterprise request and abuse monitoring, account administration, or product improvement. Map each activity and contract term separately.

Can de-identification remove the PIPL issue?

De-identification and anonymization have different effects under the statute. PIPL excludes information after anonymization from its personal-information definition, while de-identified information can remain personal information when the handling still relates to an identifiable person or can be restored with additional information. Review the transformation and the data available to the enterprise and provider. Review the data available to other recipients before treating a prompt as outside scope.

Does a human reviewer remove Article 24 concerns?

A genuine human decision path changes the facts around a solely automated decision, but Article 24 also imposes transparency and fairness duties on automated decision-making more broadly. Record what the reviewer sees and the authority to change the result. Record the action actually taken. A required click after the model recommendation gives weak evidence of human judgment when the reviewer lacks the underlying record or practical discretion.