个人信息保护影响评估：四类触发情形、八部分报告与三处衔接

个人信息保护影响评估（PIA）在不少企业里被当成一份内部风险文档：产品上线前写一版，放进共享盘，之后无人引用。但《个人信息保护法》第五十五条把它规定为特定处理活动的前置程序，第五十六条要求评估报告与处理情况记录至少保存三年。性质上，它与隐私政策不同——隐私政策面向用户，PIA 面向监管，用于证明企业在处理高风险活动之前做过判断。

一、四类法定触发情形

第五十五条列明五种情形，实务中可归为四类：

第一类，处理敏感个人信息。 生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹，以及不满十四周岁未成年人的个人信息。AI 产品中常见的是人脸核身、语音声纹、健康问诊、教育场景中的未成年人数据。

第二类，利用个人信息进行自动化决策。 内容审核、推荐排序、信用评分、额度评估均属此类。需要注意的是，只要决策结果对个人权益产生显著影响，即使没有完全自动化，也可能触发评估。

第三类，委托处理、对外提供、公开个人信息。 调用第三方模型服务、向关联公司共享、在公开场景展示用户内容，都可能落入这一类。判断的关键是信息是否离开了处理者的控制范围。

第四类，向境外提供个人信息。 包括数据出境安全评估、标准合同与认证三条通道下的各类情形。

四类之间存在重叠。一款调用境外模型服务的 AI 写作工具，可能同时触发第二类、第三类与第四类，此时应做一份覆盖全部处理活动的评估，而不是分别做三份。

二、AI 产品最容易漏判的三处

其一，用户输入中的敏感信息。 企业通常认为产品只收集账号与日志，但用户在实际使用中会粘贴病历、身份证照片、工资单。平台由此处理了敏感个人信息，即便产品设计并未要求用户这么做。判断标准是实际处理，而非设计意图。

其二，微调与评测使用用户数据。 将用户输入用于模型微调、构建评测集，属于处理目的的变化。原告知中的"提供服务"不覆盖这一目的，需要重新评估并取得相应同意。

其三，API 对外开放。 企业把模型能力以 API 形式提供给下游客户，下游客户再面向个人用户提供服务。此时企业可能同时是受托方与独立处理者，评估需要区分两类角色，分别说明。

三、报告的八部分结构

一份可用于应对监管检查的报告，通常包含八个部分：

1. 处理活动描述。 处理目的、方式、信息种类、数量、频率、涉及的系统与数据流。
2. 合法性基础。 每一项目的对应的合法性基础，以及同意的取得方式。
3. 必要性分析。 处理目的是否明确、是否限于实现目的的最小范围、保存期限是否合理。
4. 对个人权益的影响。 可能造成的后果、影响程度、受影响人群范围，特别关注未成年人、员工等弱势或从属关系场景。
5. 安全保护措施。 加密、去标识化、访问控制、审计日志、人员管理、受托方管理。
6. 风险等级与结论。 按高、中、低分级，给出是否可以开展处理的明确结论。
7. 整改措施与时限。 针对高风险项列出具体动作、责任人与完成时间。
8. 复核安排。 处理活动发生变化时的重新评估触发条件。

第五部分最容易被写成清单式套话。监管关注的不是"是否加密"，而是加密覆盖了哪些字段、密钥由谁管理、去标识化后的数据是否仍可复原。

四、与三类既有评估的衔接

四类评估的内容有重叠但不互相替代。实务中的高效做法是：以 PIA 为主线，把算法自评估与出境评估所需的信息嵌入同一套数据流描述，避免同一事实在四份文件中出现四种说法。监管交叉核对时，前后不一致比内容不足更麻烦。

五、三种常见错误做法

第一种，只做一次。 PIA 是对特定处理活动的评估，产品新增功能、更换模型供应商、改变数据用途，都应触发重新评估。把三年前的报告直接用于新产品，等于没有评估。

第二种，只写结论。 报告只有"经评估风险可控"一句话，没有影响分析与措施描述。这类报告在检查中通常被视为未实质开展评估。

第三种，评估与产品脱节。 报告描述的处理流程与系统实际情况不符，例如报告称已做去标识化，实际系统中保留明文。这类问题一旦被发现，会连带影响企业在其他事项上的陈述可信度。

六、核对清单

PIA 的价值不在于交差，而在于它迫使企业在处理活动开始之前，把"为什么处理、处理到什么程度、出了事怎么办"这三个问题写成可被检验的答案。写不出来，通常意味着产品设计本身还有没想清楚的地方。

站内相关梳理：AI 产品隐私政策、AI 企业数据合规的五大风险点、生成式 AI 备案材料清单、GDPR 与数据出境合规，以及数据合规与算法备案服务页。

最后更新：2026 年 7 月 14 日。