Does the PIPL apply to AI systems specifically?

The PIPL applies to any processing of personal information, and Article 24 addresses automated decision-making directly, so AI systems handling personal information have been in scope since 1 November 2021. The Interim Measures for Generative AI Services of 15 August 2023 add service-provider duties on top, and the content labelling measures of 1 September 2025 add output marking obligations.

What does Article 24 require in evidence terms?

For a decision made solely through automated means that significantly affects an individual, you must be able to explain it and to support the individual's right to refuse. In practice that is a per-decision record tying the input to the output and the applied logic, written when the decision request is made. A general account of how the model works does not answer a request about one person's decision.

Is a prompt to a foreign LLM a cross-border transfer?

Sending personal information in a prompt to a model endpoint outside mainland China counts as a cross-border transfer under Articles 38 to 40. Which mechanism applies depends on volume and sensitivity under the March 2024 provisions, so you need a per-request record of destination, classification, and individual count rather than a static list of vendors.

Does a generative AI filing cover the transfer obligation?

A security assessment or filing under the Interim Measures addresses the service, and the PIPL cross-border mechanism addresses the data leaving the country. They run in parallel, so a completed generative AI filing does not discharge the Article 38 to 40 obligation where the model processes personal information and sends prompts or logs abroad.

Can vendor logs satisfy the CAC?

Vendor logs reflect the model provider's view of the API call, without your identity context or your policy decisions, and they sit outside your custody. The PIPL places the obligation on the personal information processor, so the record has to exist on your side, showing who sent what, where it went, and which control fired.

China PIPL AI Audit Evidence: What the CAC Expects When a Prompt Leaves the Mainland

China regulated AI decisions three years before most jurisdictions wrote the word into statute. The Personal Information Protection Law (PIPL) took effect on 1 November 2021, and Article 24 already covered automated decision-making with transparency duties, a right to explanation, and a right to refuse decisions made solely by automated means where they significantly affect an individual. The Interim Measures for the Administration of Generative AI Services followed on 15 August 2023, and the Measures for Labelling AI-Generated Synthetic Content took effect on 1 September 2025.

A Cyberspace Administration of China review does not grade the governance deck. It asks what happened when personal information reached a model, and where that information went. The moment under examination is a single HTTPS request carrying a context window to a model endpoint. I want to walk the evidence artifacts that review expects, because Chinese AI compliance work concentrates on filings and leaves the operational record thin.

The Article 24 automated-decision record

Article 24 requires transparency and fairness in automated decision-making, prohibits unreasonable differential treatment on transaction terms, and gives an individual the right to demand an explanation and to refuse a decision made solely through automated means where the decision significantly affects their rights and interests. Answering an explanation request needs the input prompt, the output, and the policy applied at that moment, tied to that person.

This is the same evidence burden that GDPR Article 22 automated decisions creates in Europe, and a model description satisfies neither regulator. The record has to be about the one decision the individual is contesting.

The Article 55 impact assessment and its Article 56 record

Article 55 requires a personal information protection impact assessment before processing sensitive personal information, before automated decision-making, before entrusting processing to another party or disclosing personal information, and before any cross-border transfer. Article 56 sets what the assessment covers and requires the assessment report and processing records to be kept for at least three years.

A PIPIA scores a design. What it does not produce is proof the deployed system behaved the way the assessment described, and that gap is where CAC scrutiny lands. The artifact that closes it is a running log of authorized AI calls carrying identity, classification, and destination, tracked the same way as in AI audit trail requirements by regulation.

The cross-border transfer record (Articles 38 to 40)

A prompt sent to a model endpoint outside mainland China is a cross-border transfer of personal information under Articles 38 to 40. The March 2024 Provisions on Promoting and Regulating Cross-Border Data Flows set the thresholds: a CAC security assessment for transfers covering more than 1 million individuals in a year, for sensitive personal information covering 10,000 or more individuals, for any critical information infrastructure operator, and for important data. Standard contractual clauses with filing, or certification, cover 100,000 to 999,999 individuals and any sensitive personal information below the 10,000 threshold. Non-sensitive personal information for fewer than 100,000 individuals falls outside the CAC mechanisms.

Every one of those thresholds is a count. Counting requires a per-request log of the destination endpoint, its jurisdiction, and the classification and volume of data in the prompt, which is what AI data residency controls capture at the moment of transmission. A signed standard contract on file shows the mechanism exists. It does not show which prompts crossed the border or how many people they described.

The security record (Article 51)

Article 51 requires a personal information processor to adopt classification-based management, technical security measures, and internal management systems sized to the processing risk. For AI traffic that means evidence of who could send what to which model and proof the boundary held. Shared static API keys work against this by granting permanent full model access to any caller. Per-role, per-route enforcement at the request boundary produces the access record Article 51 expects, generated by enforcement rather than assembled for the review.

Why self-written application logs fail

An application that makes the AI call and also writes the compliance log is attesting to itself. That record breaks under selective logging, under suppression by the same system, and under crash-loss when the process dies after the model responds but before the commit. I set this out in You Own the AI Liability, Not the Vendor.

My candid view: the cross-border thresholds are the sharpest part of the PIPL for AI teams, because they turn a compliance question into a counting problem, and nobody can count traffic they never logged. Article 66 puts up to RMB 50 million or 5% of prior-year turnover behind that arithmetic.

DeepInspect

This is the evidence layer PIPL-bound AI programmes usually lack. DeepInspect sits inline between your users or agents and the LLM APIs they call. For every request it evaluates identity, data classification, and destination, then writes a signed, tamper-evident record before the response returns. The record holds the caller, the classification in the prompt, the model endpoint and its jurisdiction, the decision applied, and the response.

When the CAC asks what personal information reached which model, whether an Article 24 automated decision occurred, and how many individuals were described in data that left the mainland, the answer is a query against records the application never controlled. The PIPL controls mapping shows how each article lines up with an enforcement point. Book a technical deep dive at deepinspect.ai.