第七十一章 工作流二十五：数据合规扫描
什么时候用
目标公司有 App、小程序或网站，个人信息是它业务的一部分。三个时点会用到：投前判断这家公司的数据是资产还是负债；申报前补数据合规专项；收购一家靠流量和用户画像挣钱的公司，看它有没有踩线。
这个工作流只解决一个具体问题：它说的和它做的，是不是一回事。隐私政策是自我陈述，抓包记录是行为证据。只审政策，等于让被调查对象自己出题；只抓包不看政策，你不知道哪些行为它本来就没打算告诉你。两样放在一起，差异才有意义。
适用范围要划清。它查的是「声明与行为的一致性」，不查数据出境、数据分类分级、重要数据识别、算法备案。这几项要另开工作流，材料和判断口径都不同：数据出境看安全评估与标准合同那一路，重要数据要看行业目录，算法备案看推荐算法那套文件。别把六件事塞进一个提示词，塞进去它只会给你一份看起来全面、每条都浅的清单。
还有一层容易被忽略：数据合规的结论高度依赖时点。同一款 App，2023 年版和 2026 年版的采集行为可能完全不同，监管口径也在变。所以材料必须带版本号和日期，产出必须标时点。没有时点的数据合规表，在报告里等于没有——读者不知道你说的是哪一版。
指令
你是我的尽调助理，只做提取、比对和列差异，不做合规结论。凡涉及「是否违法」「是否情节严重」「是否取得有效同意」的问题，一律标注「需律师判断」。
【说明】下文 App 名称、版本号、日期、采集项均为占位符，请替换为本项目实际数据。
【材料】
材料一：隐私政策全文（版本号 V__，生效日期 ____，抓取日期 ____，抓取渠道：App 内 / 官网）
材料二：权限清单（Android 与 iOS 分列，含权限名称、申请时机、用途说明文案）
材料三：抓包记录（工具 ____；采集区间 ____ 至 ____；覆盖场景：首次安装启动、注册登录、浏览、搜索、下单、支付、客服、后台驻留、退出后重新唤起）
材料四：第三方 SDK 清单（名称、提供方、版本、用途、初始化位置与时机、是否在隐私政策中披露）
材料五：小程序、H5、公众号的同类材料（如有，分别标注）
材料六：《常见类型移动互联网应用程序必要个人信息范围规定》中与本 App 类型对应的条目（请引用规定原文逐条列出；不确定归类时列候选类别并说明理由，不要硬归）
【任务】
1. 从材料一提取：声明的采集项、收集目的、使用场景、共享或委托处理的第三方、保存期限、用户权利条款。逐项注明在隐私政策第几节。
2. 从材料三提取：实际发生的网络请求与本地读取，按「采集项—发生场景—发生时机—频次—接收方域名」列。
3. 做四张比对表：
表 A 声明有、本次未见（再分「政策虚列」与「场景未覆盖」两种）
表 B 实际有、声明无（未披露采集）
表 C 同意前采集（首次启动、点击同意之前、拒绝授权后仍采集）
表 D 超必要范围（对照材料六逐项比对）
4. SDK 单列一张表：是否披露、初始化时机、是否在同意前初始化、收集哪些字段、是否含热更新配置。
5. 输出「需律师判断清单」，每条写：争点、涉及材料、还缺什么证据。
【输出】
第一部分：四张比对表，列为：采集项、政策声明（节号）、抓包证据（时间戳与域名）、时机、判定类别、备注。
第二部分：SDK 表。
第三部分：需律师判断清单。
第四部分：抓包盲区（哪些场景、哪些端、哪类采集方式没有覆盖）。
【边界】
- 抓包记录里没有的，写「本次抓包未见」，不写「未采集」
- 隐私政策没写的，写「政策未披露」，不写「未收集」
- 不引用具体法条条号，只写规定名称，条号我自己核
- 每条结论必须能追到材料几、第几节或第几行
- 不要写「建议尽快整改」这类空话，写缺哪份证据、向谁要它会给出什么
四张表加两张清单。示例数据如下。
| 采集项 | 政策声明 | 抓包证据 | 时机 | 判定 |
|---|---|---|---|---|
| 设备标识（OAID） | 3.2 节「设备信息」 | 00:00:03 GET api.xxx.com/init?oaid=… | 首次启动，同意前 | 表 C |
| 应用列表 | 未披露 | 00:00:05 POST api.xxx.com/collect，字段 app_list | 首次启动 | 表 B |
| 粗略位置 | 3.4 节「附近门店」 | 02:11 浏览页触发，仅前台 | 同意后 | 表 A（场景未覆盖） |
| 通讯录 | 未披露 | 本次未见 | — | — |
| 剪贴板 | 未披露 | 本次未见（抓包看不到本地读取） | — | 盲区 |
SDK 表：
| SDK | 提供方 | 初始化时机 | 收集字段 | 是否披露 | 备注 |
|---|---|---|---|---|---|
| 某统计 SDK | 某公司 | Application.onCreate | 设备标识、应用列表、IP | 否 | 同意前初始化 |
| 某推送 SDK | 某公司 | 首屏后异步 | 设备标识、厂商通道 token | 是（3.6 节） | 含热更新配置 |
| 某分享 SDK | 某公司 | 点击分享时 | 无（仅唤起） | 是 | 未见异常 |
需律师判断清单：
| 序号 | 争点 | 涉及材料 | 还缺什么 |
|---|---|---|---|
| 1 | 应用列表是否属于实现功能所必需 | 材料三、材料六 | 该功能的实现说明、技术文档；SDK 官方说明 |
| 2 | 首次启动即初始化统计 SDK，是否属于同意前收集 | 材料三、材料四 | SDK 初始化代码位置、启动流程说明 |
| 3 | 隐私政策未列该统计 SDK，是否构成未披露共享 | 材料一、材料四 | 数据处理协议、SDK 隐私政策链接 |
它一般还会在末尾加一句「建议对上述问题进行整改并完善隐私政策」。这句删掉——第三部分已经写了缺什么、向谁要，多这一句只是占篇幅。
要留意它把「本次抓包未见」写成「未采集」。这两个词在报告里的分量完全不同：前者是取证范围的事实，后者是对行为的事实陈述。写错一个词，对方一句「你怎么知道我没采集」就把整段推翻了。
怎么判断
能直接用的：四张表的差异定位、时间戳、域名、SDK 初始化时机。这部分是机械比对，它做得比人快，也不容易漏行。表 B 和表 C 尤其好用——这两张表的价值在于「把没写出来的东西列出来」，人读一百页政策也未必能对上抓包日志。
必须改的：
- 「业务必需」不能由它定。要按《常见类型移动互联网应用程序必要个人信息范围规定》逐类比对。该规定按 App 类型分别列举必要信息，比如地图导航类、网络约车类、即时通信类、网络购物类、餐饮外卖类、快递物流类，各自的范围不同；不在列举范围内的，原则上不属于必要信息。它最常见的错误是把行业惯例当必要，比如把通讯录当成社交类 App 的必要信息——规定里没有这一项。
- 「同意」要分层次。一般同意、单独同意、书面同意是三套规则。处理敏感个人信息、向第三方提供、公开披露、处理已公开的个人信息，要求各不相同。它会把「隐私政策里写了」当成「已取得同意」，这是两件事：写了是告知，同意要有独立的交互动作和记录。
- 时点要卡死。首次启动、点击同意前、拒绝授权后、后台驻留、退出后重新唤起，这五个时点的行为要分开看。抓包时间戳必须能与操作日志对上，否则「同意前」这个结论站不住。它有时会把「首次启动后 5 秒内」一律算作同意前，但用户可能在第 3 秒就点了同意。
- 版本要对应。抓包的是 V__ 版本，隐私政策是 ____ 日生效的版本。版本错配，整张表作废。它不会主动提醒这件事，因为提示词里没让它比版本。
- 表 A 要拆成两类。政策虚列是「写了但没做」，属于虚假告知；场景未覆盖是「做了但这次没抓到」，属于取证不足。两者风险等级和下一步动作完全不同，它常混成一类。
它做不到的：
- 看不见本地读取。抓包只看得见网络请求。SDK 在本地读通讯录、剪贴板、相册、传感器，不产生请求也一样能读。这类行为要靠系统权限调用记录、AppOps、动态分析工具，抓包补不了。
- 判断不了同意是否有效。同意是否自愿、有没有捆绑授权、拒绝后基础功能还能不能用，这些要看交互设计和实际测试。它读的是文本和日志，看不到界面。
- 判断不了情节与后果。会不会被通报、下架、罚款，罚多少，看监管口径、整改态度、影响范围。这些不在材料里。
- 看不见热更新。很多 SDK 在运行时下发配置，今天抓不到的采集，明天配置一改就有了。它只能就当天这次抓包说话。
- 分不清「共享」与「委托处理」。两者在告知和合同上的要求不同，它常按「第三方」一锅端。这一点必须人分。
追问示例
第一轮：专查 SDK
请只针对第三方 SDK 做一张表：哪些在隐私政策中未披露、哪些在同意前初始化、哪些带热更新配置、哪些嵌在 H5 或小程序里。每条写清证据（代码位置、日志时间戳、配置文件），没有证据的写「未取得证据」。
这一轮的价值在于把 SDK 从「采集项」里单独拎出来。SDK 是数据合规里最容易漏的一块：它不在公司的代码里写采集逻辑，但它在跑；公司说自己没收集，技术上可能真不知道 SDK 收了什么。
第二轮：按规定逐类判定
请把本 App 归入《常见类型移动互联网应用程序必要个人信息范围规定》的类别，列出该类别的必要信息原文，再逐项比对我们抓到的采集项。超出列举范围的单独列出。归类不确定的，列候选类别和理由，不要硬归。
它会给出「本 App 属于网络购物类」这样的判断，附上该类别的条目，然后逐项标「在范围内」「超出」「无法判断」。这一轮的产出可以直接进报告，因为它带了规定的原文，读者能自己核。
第三轮：列盲区
请列出这次抓包没有覆盖的场景、端和采集方式，并说明每一类要怎么补：补抓需要什么条件、大概需要多久、可能拿到什么。
它会给出：iOS 端未抓、小程序未抓、H5 内嵌页未抓、本地读取未覆盖、后台唤醒未覆盖。每一类补抓的条件不同，iOS 要真机加描述文件，小程序要开发者工具或真机代理，H5 要看 WebView 调试开关。这一轮把「取证不足」变成了可执行的补证计划。
常见误用
误用一：只看隐私政策不抓包。
❌「这是目标公司的隐私政策，请审查是否合规。」
政策是它说自己怎么做，不是它实际怎么做。只审政策，你审的是文案水平，不是合规水平。而且政策往往是模板改的，写得越规范，越容易让人放松警惕。
正确做法：政策与抓包同时给，让它做差异表。政策单独看只用于一件事——看它有没有把该说的说了（告知义务的形式审查）。
误用二：把政策写的当实际做的。
❌「政策里写了仅在同意后收集设备信息，这一项没问题。」
这句话只是引述，不是核实。表 C 存在的意义就是打这个假设。实务里最常见的情形是：政策写得很规范，但 SDK 在 Application.onCreate 里就初始化了，同意弹窗还没弹出来，设备标识已经上传。
正确做法：每一项声明都要在抓包里找对应证据。找不到证据的，写「未取得证据」，不写「符合」。
误用三：一套政策比所有端。
❌ 用 App 的隐私政策，去比对小程序和 H5 的采集行为。
App、小程序、公众号、H5 往往各有各的隐私政策，版本还不一致，有的甚至没有独立政策。拿 App 的政策去比小程序的行为，表 B 会全是「未披露」，实际是小程序另有政策，只是你没拿到。
正确做法：分端建表，每端配自己的政策版本。最后再做一张「多端政策一致性」表，看同一项采集在不同端的表述是否冲突——这张表本身就是一个发现问题的入口。
自检
- [ ] 抓包覆盖了首次启动、同意前、拒绝授权后、后台驻留、退出后唤起这五个时点吗？
- [ ] 抓包版本与隐私政策版本对得上吗？政策生效日期是哪天？
- [ ] 表 A 里分了「政策虚列」和「场景未覆盖」吗？
- [ ] 「必要信息」是按规定逐类比对，还是按行业惯例？
- [ ] SDK 单独查了吗？初始化时机、是否同意前、是否披露、有无热更新？
- [ ] 本地读取（通讯录、剪贴板、相册、传感器）另行核查了吗？
- [ ] 有没有把「本次抓包未见」写成「未采集」？
- [ ] 产出里还有没有「合规」「不合规」「情节严重」这类结论？