APP个人信息保护合规检查技能
面向公司法务、数据合规律师或合规顾问的APP个人信息保护合规评审工具包。 采用"合规事实查明 + 声明一致性核验"两阶段审查方法论，覆盖11大合规模块53检查项，法规依据通过运行时检测的MCP后端实时核验。从"业务部门提交的APP材料"到"可直接交付的合规审查报告与整改清单"，一个包闭环完成。
概述
本技能为中国移动应用（APP）个人信息保护合规评审提供系统化、结构化的检查框架。以《个人信息保护法》《网络安全法》《数据安全法》为核心依据，结合监管执法实践与行业合规标准，建立覆盖APP个人信息处理全生命周期的合规检查体系。
所有法律法规依据均经法规核验MCP后端核验，确保法规名称、文号、条款编号及现行有效性准确。详见 references/law-library.md（含24部法律法规、国家标准及团体标准）。
MCP法规核验后端（能力槽设计）
本技能的法规核验功能不绑定任何特定MCP产品。skill运行至阶段四（法规核验）时，自动扫描用户本地已连接的MCP连接器，按以下逻辑选择后端：
运行时检测逻辑：
- 扫描已连接的MCP连接器，检测以下后端是否可用：
| 后端 | 检测方式 | 工具前缀 |
|---|
| 北大法宝（pkulaw） | 检测 mcp__pkulaw__ 前缀工具是否可用 | mcp__pkulaw__mcp-law/ |
| 华宇元典（yuandian） | 检测 yuandian_ 前缀工具是否可用 | yuandian_rh_fg_search 等 |
-
根据检测结果选择后端：
- 0个可用 → 报告中标注"⚠️ 未检测到法规核验MCP后端，法规依据未能实时核验，建议人工确认"，跳过MCP核验步骤
- 1个可用 → 自动使用该后端
- 2个均可用 → 询问用户选择使用哪一个后端进行本次核验
-
询问用户时提供以下信息辅助决策：
| 后端 | 优势 |
|---|
| 北大法宝 | WorkBuddy内置，零额外配置，返回TimelinessDic字段直接判断时效性 |
| 华宇元典 | 额外支持法律幻觉校验接口，可批量校验报告中法律引用准确性 |
后端确定后，按对应工具映射执行核验：
| 核验动作 | 北大法宝 | 华宇元典 |
|---|
| 核验法规现行状态 | mcp__pkulaw__mcp-law/get_law_list(title=...) | yuandian_rh_fg_search(keyword=...) |
| 核验条款内容 | mcp__pkulaw__mcp-law-search-service/get_article(...) | yuandian_rh_ft_detail(...) |
| 检索替代条款 | mcp__pkulaw__mcp-law-search-service/search_article(...) | yuandian_law_vector_search(...) |
华宇元典MCP配置方式（如用户尚未配置）：
{
"yuandian-law": {
"type": "http",
"url": "https://open.chineselaw.com/mcp/law/stream",
"headers": {
"Accept": "application/json, text/event-stream",
"Authorization": "Bearer YOUR_YUANDIAN_API_KEY"
}
}
}
适用场景
- APP上线前合规评审：新APP或大版本更新上线前，全面排查个人信息保护合规风险
- 版本迭代合规自查：小版本迭代中涉及个人信息收集行为变化时，增量审查变更部分
- 监管通报整改定位：收到工信部通报、应用商店下架通知后，定位违规项并生成整改清单
- 并购尽调数据合规审查：投资并购场景下，对标的APP进行数据合规尽职调查
- SDK接入评估：新增第三方SDK前评估其个人信息处理行为是否符合合规要求
审查边界（重要）
本技能的审查范围严格限定在法务/律师通过业务部门提供的APP材料即可自闭环完成的检查项。以下事项不纳入本技能，因为它们需要额外上下文或属于不同阶段的工作：
| 不纳入事项 | 原因 | 应在何时处理 |
|---|
| 数据泄露应急响应预案 | 需要企业安全运营制度文档，非APP审查材料可覆盖 | 监管检查应对或专项安全审计 |
| 数据全生命周期管理制度 | 属企业内部数据安全管理体系，非APP层面审查 | 企业数据合规体系建设 |
| 个人信息保护影响评估（PIA） | 属产品设计阶段专项评估，需独立开展 | 产品立项或重大功能变更时 |
| 数据分类分级管理制度 | 属企业数据治理体系，非APP审查范畴 | 企业数据治理体系建设 |
| 网络安全等级保护测评 | 属网络安全合规专项，需持证机构测评 | 按等保2.0要求定期开展 |
| 合规审计（个保法§54） | 属定期审计制度，非上线前审查 | 按法定周期开展 |
如审查中发现上述事项的缺口，在报告中以提示性建议方式指出，但不作为合规判定项。
两阶段审查方法论
对APP的合规审查分为两大阶段：先查明合规事实，再核验声明与事实的一致性。大多数合规风险恰恰隐藏在"声明"与"事实"的偏差中，因此第二阶段是审查的核心。
阶段一：合规事实查明
从文本取证与技术取证两个维度采集合规事实：
| 取证维度 | 审查对象 | 方法 |
|---|
| 文本取证 | 隐私政策、用户协议、权限弹窗文案、第三方共享说明、双清单 | 逐条文本审查，对照法规要求与检查清单 |
| 技术取证 | APK安装包内的AndroidManifest.xml、权限声明、SDK包名、内嵌隐私政策文本/链接、资源文件 | 解包APK提取技术事实，使用 scripts/apk_analyzer.py 自动化分析 |
阶段二：声明一致性核验
将文本声明与技术事实、客户材料与安装包实际内容逐项比对，定位不一致之处（如隐私政策披露A/B/C三个SDK，安装包实际还有D；或隐私政策未声明某权限，APK却实际申请）。
技术取证获取的是"声明了什么、内嵌了什么、疑似接入了什么"，不等同于运行时实际调用行为。运行时真实行为需动态测试进一步确认，在报告中应明确标注静态取证与动态验证的边界。
输入材料要求
输入材料的完整性直接决定审查深度。启动审查前，须向业务部门发送 assets/input-materials-template.md 收集以下材料：
必需材料（缺一不可）
- APP安装包（APK文件；iOS为IPA，但本技能以Android APK静态分析为主）
- 最新版隐私政策（完整文本，含第三方SDK清单）
- 用户协议/服务协议
- SDK清单（含SDK名称、所属公司、功能、收集的个人信息类型、收集目的、使用场景）
- 权限使用清单（含权限名称、使用场景、目的说明）
- 业务功能清单（基本功能与附加功能划分）
- 已收集个人信息清单（双清单之一）
- 与第三方共享个人信息清单（双清单之一）
可选材料（影响审查完整度，如不适用可跳过）
收到材料后，逐项确认是否适用。某些材料在特定场景下可能不需要，审查人员须根据APP实际情况自行判断：
- 个性化推荐/算法推送设置说明（如APP无个性化推荐功能则不需要）
- 账号注销流程说明（如APP无账号体系则不需要）
- 投诉举报渠道说明（如已在隐私政策中完整说明则可不需要）
- 适老化改造说明（如APP不属于适老化改造重点APP范围则不需要）
- 儿童个人信息保护规则（如APP不涉及未成年人业务则不需要）
- 数据出境情况说明（如APP不存在跨境传输则不需要）
- 自动续费/会员订阅机制说明（如APP无自动续费功能则不需要）
提示：如某项可选材料不适用，在材料收集清单中标注"不适用"并说明原因即可，不影响审查启动。如某项材料适用但业务部门未能提供，在报告中将对应检查项标注为"材料缺失，未能完成审查"。
收到材料后，运行 scripts/material_validator.py 校验材料完整性，生成缺失项清单并提示业务部门补充。
# 校验材料完整性，输出缺失项清单与完整度评分
python scripts/material_validator.py --materials-dir /path/to/materials/
工作流程
阶段一：材料收集与校验（Day 1）
- 向业务部门发送
assets/input-materials-template.md 材料收集清单
- 收到材料后运行
scripts/material_validator.py 校验完整性
- 列出缺失材料，要求业务部门在约定时限内补充
阶段二：技术核验（Day 2-3）
- 运行
scripts/apk_analyzer.py 对APK安装包进行静态分析，提取：
- AndroidManifest.xml中声明的全部权限
- 安装包内识别的第三方SDK（基于包名特征库匹配）
- 内嵌的隐私政策文本或链接
- 应用基本信息（包名、版本号、targetSdkVersion等）
- 将技术取证结果保存为结构化JSON，供后续一致性核验使用
# APK静态分析：提取权限、识别SDK、搜索内嵌隐私政策
# 脚本启动时会自动打印能力边界告知，并检测是否安装了增强工具
python scripts/apk_analyzer.py --apk /path/to/app.apk --output apk_report.json --format summary
能力边界：APK分析脚本基于Python标准库零依赖运行，采用正则匹配+字节搜索方式。已知局限：权限提取可能遗漏非标格式、SDK识别仅覆盖未混淆的主流包名、包名版本号可能不准确。脚本启动时自动检测androguard/aapt2/apktool/jadx是否安装，如已安装则提示审查人员可用其交叉验证。
详细APK分析方法见 references/apk-analysis-guide.md。
阶段三：合规事实查明与声明一致性核验（Day 4-7）
- 对照
references/checklist-full.md 中的11大模块检查项，先完成文本取证（审查文本材料）
- 将隐私政策声明的SDK、权限、个人信息类型与APK技术取证结果逐项比对（一致性核验）
- 将客户提供的SDK清单与APK识别的SDK逐项比对（一致性核验）
- 将权限使用清单与AndroidManifest.xml声明的权限逐项比对（一致性核验）
- 记录每项检查的事实发现、合规判定、风险等级
阶段四：法规依据实时核验（Day 7）—— MCP条文锚定
数据合规领域法律法规更新频繁（如《网络安全法》2025年10月已修正），skill必须在每次运行时核验所依据法规的现行有效性，避免引用已失效或已修订的条款。
核验机制：通过 references/article-anchors.md 条文锚定表，将每个检查项与具体法规条款建立程序化映射（共72个锚点）。每次运行时，先扫描已连接的MCP后端（见上方"MCP法规核验后端"能力槽设计），确定本次使用的后端后，按对应工具映射逐锚点核验。
核验流程：
- 扫描已连接MCP连接器，检测pkulaw/yuandian可用性（0个→跳过并警告；1个→自动使用；2个→询问用户选择）
- 加载
references/article-anchors.md，获取全部锚点清单
- 对每个锚点，按核验频率策略执行：
every_run 类锚点（个保法、网安法、数据安全法、认定方法，共42个）：每次运行必核验quarterly 类锚点（必要范围规定、移动互联网应用程序信息服务管理规定、164号文、524行动通知、26号文、算法推荐规定、广告管理办法、未成年人保护法、未成年人网络保护条例，共23个）：如距上次核验超90天则核验annual 类锚点（GB/T国家标准，共7个）：标注"需手动核验"，因法规MCP后端通常不收录国家标准
- 根据活跃后端调用对应MCP工具核验：
后端为pkulaw（北大法宝）时：
# 核验法规现行状态（检查TimelinessDic字段是否为"现行有效"）
mcp__pkulaw__mcp-law/get_law_list(title="个人信息保护法")
# 核验具体条款内容
mcp__pkulaw__mcp-law-search-service/get_article(title="中华人民共和国个人信息保护法", number="十七")
# 法规已修订时检索替代条款
mcp__pkulaw__mcp-law-search-service/search_article(text="敏感个人信息单独同意")
后端为yuandian（华宇元典）时：
# 核验法规现行状态（检查返回结果中的时效性字段）
yuandian_rh_fg_search(keyword="个人信息保护法")
# 核验具体条款内容
yuandian_rh_ft_detail(law_title="中华人民共和国个人信息保护法", article_no="十七")
# 法规已修订时检索替代条款
yuandian_law_vector_search(query="敏感个人信息单独同意")
- 核验法规现行状态：按活跃后端调用对应工具
- pkulaw:
mcp__pkulaw__mcp-law/get_law_list(title=<law_search_key>)，检查 TimelinessDic 字段
- yuandian:
yuandian_rh_fg_search(keyword=<law_search_key>)，检查返回结果中的时效性字段
- 如显示"废止或失效"，标记该锚点为失效，暂停引用
- 如存在多个版本，确认引用最新版本（如移动互联网应用程序信息服务管理规定须用2022修订版而非2016原版）
- 核验条款内容：按活跃后端调用对应工具
- pkulaw:
mcp__pkulaw__mcp-law-search-service/get_article(title=<law_title>, number=<law_article_no>)
- yuandian:
yuandian_rh_ft_detail(law_title=<law_title>, article_no=<law_article_no>)
- 确认条款内容与skill引用的一致
- 检索替代条款（如法规已修订）：按活跃后端调用对应工具
- pkulaw:
mcp__pkulaw__mcp-law-search-service/search_article(text=<关键词>)
- yuandian:
yuandian_law_vector_search(query=<关键词>)
- 将核验结果记入运行日志（JSON格式，含每个锚点的状态、核验时间、备注）
- 对失效或已修订的依据，在报告中标注警告并调整引用条款
核验结果处理规则：
- 法规已废止 → 报告标注"⚠️ 原依据法规已废止，建议核实替代法规"
- 法规已修订 → 检索新条款，更新引用，报告标注"本报告已采用最新修订版条款"
- 法规MCP后端无法返回 → 报告标注"⚠️ 法规状态未能通过MCP核验，建议人工确认"
- 国家标准（GB/T系列）→ 报告标注"需通过全国标准信息公共服务平台人工核验"
- 对每项不合规发现，引用
references/law-library.md 中的具体法规条款，并附条文锚点编号（如 [A014]）
- 条文锚定表的核验结果作为报告附件，证明依据的现行有效性
阶段五：报告生成与交付（Day 8-10）
- 运行
scripts/report_generator.py 或基于 assets/compliance-report-template.md 生成合规评审报告
# 方式一：交互式输入检查结果，生成Markdown报告
python scripts/report_generator.py --interactive --output compliance_report.md
# 方式二：从JSON文件读取检查结果，附带APK分析报告
python scripts/report_generator.py --input check_results.json --apk-analysis apk_report.json --output compliance_report.md
- 生成
assets/remediation-template.md 整改清单，按优先级排序
- 向业务部门交付：合规评审报告 + 整改清单 + 法规依据索引
11大合规检查模块
| 模块 | 检查重点 | 核心法规依据 |
|---|
| M1 隐私政策合规 | 政策完整性、首次运行提示、易于访问阅读、双清单 | 个保法§7、§17；认定方法§1-2；524行动通知；26号文 |
| M2 知情同意 | 同意前不收集、拒绝后不频繁索要、不超授权、撤回途径 | 个保法§13-16、§22；认定方法§3；26号文 |
| M3 最小必要 | 与业务功能相关、可拒绝非必要、不强制捆绑、频率合理 | 个保法§6、§19；必要范围规定；认定方法§4；GB/T 41391-2022；T/TAF 077系列 |
| M4 权限管理 | 权限声明完整、申请同步告知、调用场景对应、拒绝机制 | 个保法§13-16；认定方法§3-4；164号文；26号文；T/TAF 078.4 |
| M5 SDK与第三方 | SDK清单完整、声明规范、第三方应用接入、自启动 | 个保法§23；认定方法§5；164号文；26号文；T/TAF 078.10 |
| M6 敏感个人信息 | 敏感信息识别、单独同意、必要性、安全措施、实名认证合规 | 个保法§28-32；GB/T 35273-2020；认定方法§3-4；网安法§24 |
| M7 用户权利 | 注销账号、更正删除、撤回同意、投诉举报、便捷卸载 | 个保法§44-50；认定方法§6；164号文；26号文 |
| M8 广告合规 | 广告标识、弹出、关闭、分发、未成年人广告、不误导 | 互联网广告管理办法§9-10、§14；广告法§14、§43-44；164号文；26号文；T/TAF 078.7 |
| M9 数据安全（展示与传输层） | 去标识化展示、加密传输、明文传输检查 | 个保法§51；网安法§21、§42；数安法§27 |
| M10 特殊场景 | 儿童、适老化、数据出境、个性化推荐（含禁止差别待遇）、自动续费 | 个保法§31、§36、§38-40；未保法；适老化通知；算法推荐管理规定§10、§15、§17、§24；T/TAF 078.2 |
| M11 分发平台信息明示 | APP在分发平台的信息明示、分发行为规范（仅适用于具有分发功能的APP）、备案号展示 | 移动互联网应用程序信息服务管理规定(2022)；164号文；26号文；APP备案工作通知 |
每个模块的完整检查项（含检测标准、违规情形、合规建议、法规条款）见 references/checklist-full.md（11大模块，53检查项）。
输出交付物
1. 合规评审报告
基于 assets/compliance-report-template.md 生成，包含：
- 执行摘要：APP基本信息、审查范围、总体合规率、重大风险项概述
- 合规总览表：11大模块的合规状态（✅合规 / ⚠️需关注 / ❌不合规 / —不适用），四色标注
- 逐项检查结果：每项含检查项编号、检查内容、法规依据、事实发现、风险等级（高/中/低）、整改建议
- 一致性核验发现：文本声明与技术事实不一致的清单
- 法规依据索引：本报告引用的全部法律法规条款汇总
2. 整改清单
基于 assets/remediation-template.md 生成，按优先级排序：
- P0 紧急（上线前必须修复）：违反法律强制性规定、存在下架风险
- P1 高优（限期修复）：监管通报高频问题、用户权益影响较大
- P2 中优（版本迭代修复）：规范性瑕疵、完善性要求
- P3 低优（长期优化）：最佳实践建议
法规依据核验方法
本技能引用的法律法规均通过用户配置的MCP后端核验。核验方法：
- 法规名称与文号以
references/law-library.md 为准
- 读取
assets/mcp-backends.yaml 确认活跃后端（pkulaw或yuandian）
- 如需确认法规是否被修改或废止，按活跃后端调用对应工具检索
- 对于国家标准（GB/T系列），法规MCP后端可能未收录，通过官方渠道确认现行版本
重要提示：法规持续更新，使用本技能前应确认以下关键法规为最新版本：
- 《网络安全法》2025年10月修正，2026年1月1日施行
- 《移动互联网应用程序信息服务管理规定》使用2022修订版
资源说明
references/（审查时按需加载）
| 文件 | 内容 | 加载时机 |
|---|
law-library.md | 经MCP后端核验的法规依据库（法规名称、文号、条款摘要、现行状态） | 引用法规依据时 |
article-anchors.md | 条文锚定表（72个锚点，检查项与法规条款的程序化映射，支持双后端MCP核验） | 每次运行阶段四法规核验时 |
checklist-full.md | 11大模块完整检查清单（检测标准、违规情形、合规建议） | 逐项审查时 |
input-materials-guide.md | 输入材料详细格式要求与采集指引 | 材料收集阶段 |
apk-analysis-guide.md | APK静态分析方法、工具使用、结果解读 | 技术核验阶段 |
scripts/（可执行脚本）
| 脚本 | 功能 |
|---|
apk_analyzer.py | APK解包与静态分析：提取权限、识别SDK、提取内嵌隐私政策 |
material_validator.py | 输入材料完整性校验：检查必需材料是否齐备 |
report_generator.py | 合规检查报告生成：汇总检查结果输出Markdown报告 |
assets/（输出模板）
| 文件 | 用途 |
|---|
input-materials-template.md | 发送给业务部门的材料收集清单模板 |
compliance-report-template.md | 合规评审报告输出模板 |
remediation-template.md | 整改清单输出模板 |
使用限制
- 本技能提供合规自查辅助，不构成正式法律意见
- APK静态分析不等同于运行时行为验证，动态行为需动态测试确认
- 涉及重大合规决策或监管调查，须咨询专业律师
- 法规持续更新，使用前应核验法规最新状态
- iOS（IPA）分析能力有限，本技能以Android APK分析为主
Tips
- 各检查项的实操要点已内嵌于
references/checklist-full.md 对应检查项的"实操要点"标注中，审查时随规则一起呈现，不会遗漏
- 《认定方法》总共只有6条，分别对应6大类违规行为，引用时切勿编造不存在的条款编号（如§7-§11均不存在）
- 静态取证获取的是"声明了什么、内嵌了什么、疑似接入了什么"，不等同于运行时实际调用行为——报告中凡涉及运行时行为的结论须标注"需动态测试确认"
- 法规依据引用时须附条文锚点编号（如[A014]），便于MCP核验时追溯