Personal Information Protection Impact Assessment: Four Triggers, Eight Sections and Three Interfaces

In many companies the personal information protection impact assessment (PIA) is treated as an internal risk document: drafted once before launch, stored on a shared drive, never cited again. But Article 55 of the Personal Information Protection Law makes it a precondition for specified processing activities, and Article 56 requires the report and the processing record to be retained for at least three years. Its character differs from the privacy policy: the policy addresses users, the PIA addresses the regulator, and its function is to evidence that the company made a judgment before undertaking high-risk processing.

1. Four statutory triggers

Article 55 lists five situations, which in practice fall into four categories.

First, processing sensitive personal information. Biometrics, religious belief, specific identity, medical health, financial accounts, whereabouts, and the personal information of minors under fourteen. In AI products the common instances are face verification, voiceprints, health consultation and minors’ data in education.

Second, using personal information for automated decision-making. Content moderation, recommendation ranking, credit scoring and limit assessment all fall here. Where the outcome has a material effect on an individual, the trigger may apply even if the decision is not fully automated.

Third, processing on instruction, provision to third parties, or public disclosure. Calling a third-party model service, sharing with affiliates, or displaying user content publicly may all fall within this category. The test is whether the information leaves the processor’s control.

Fourth, providing personal information abroad. This covers the security assessment, standard contract and certification channels.

The categories overlap. An AI writing tool that calls an overseas model may trigger the second, third and fourth at once; in that case one assessment covering all processing activities should be prepared rather than three separate documents.

2. Three points most often missed in AI products

First, sensitive information inside user input. Companies generally assume the product collects only account and log data, while users in practice paste medical records, identity documents and payslips. The platform thereby processes sensitive personal information even though the product design did not ask for it. The test is actual processing, not design intent.

Second, fine-tuning and evaluation on user data. Using user input for fine-tuning or to build an evaluation set changes the purpose of processing. The original notice covering service delivery does not extend to it; a fresh assessment and appropriate consent are required.

Third, opening the model through an API. Where a company supplies model capability by API to downstream customers who then serve individuals, the company may be both a processor and an independent controller. The assessment must distinguish the two roles and address each.

3. Eight sections of a usable report

A report capable of withstanding inspection generally contains eight sections.

1. Description of the processing activity. Purpose, method, categories, volume, frequency, systems and data flow.
2. Lawful basis. The basis corresponding to each purpose and how consent was obtained.
3. Necessity analysis. Whether the purpose is specific, whether processing is limited to the minimum scope, whether retention is reasonable.
4. Impact on individual rights. Possible consequences, severity, the population affected, with particular attention to minors and to employment relationships where consent is structurally constrained.
5. Safeguards. Encryption, de-identification, access control, audit logging, personnel management and processor management.
6. Risk rating and conclusion. Rated high, medium or low, with an explicit conclusion on whether processing may proceed.
7. Remediation and timetable. Specific actions, owners and deadlines for high-risk findings.
8. Review arrangements. The triggers for reassessment when the processing activity changes.

The fifth section is the one most often reduced to a checklist of platitudes. Regulators are less interested in whether encryption exists than in which fields it covers, who manages the keys, and whether de-identified data can still be re-identified.

4. Interfaces with three existing assessments

The four overlap in content but do not substitute for one another. The efficient practice is to use the PIA as the spine and embed the information needed for the algorithm self-assessment and the transfer assessment into the same data-flow description, so that the same facts are not described four different ways. When regulators cross-check, inconsistency is more troublesome than incompleteness.

5. Three common errors

Doing it once. A PIA assesses a specific processing activity. New features, a change of model provider or a change of data use should trigger reassessment. Applying a three-year-old report to a new product amounts to no assessment at all.

Writing only the conclusion. A report containing a single sentence that risk is manageable, without impact analysis or measures, is generally treated as no substantive assessment.

Assessment divorced from the product. The report describes a process that differs from the system — for example, stating that de-identification has been applied while plaintext is retained. Once discovered, this undermines the credibility of the company’s statements on other matters as well.

6. Checklist

The value of a PIA is not in satisfying a filing requirement but in forcing the company, before processing begins, to write testable answers to three questions: why process at all, how far to go, and what happens if something goes wrong. An inability to write them usually means the product design itself is not yet settled.

Related reading: privacy policies for AI products, five data-compliance risks for AI companies, the generative AI filing materials checklist, GDPR and cross-border data transfers, and the data compliance and algorithm filing service pages.

Last updated: 14 July 2026.