app-compliance-review

name	app-compliance-review
version	1.0.0
description	中国APP个人信息保护合规检查技能。面向公司法务、数据合规律师或合规顾问，对移动应用程序（APP）开展完整的个人信息保护合规评审，可直接面向业务部门交付合规审查报告与整改清单。采用"合规事实查明 + 声明一致性核验"两阶段审查方法论，覆盖11大合规模块53检查项，法规依据通过运行时检测的MCP后端（北大法宝/华宇元典）实时核验。触发关键词：APP合规检查、个人信息保护合规、隐私政策审查、APP合规评审、数据合规审查、移动应用合规、SDK合规、权限合规、个人信息保护法合规、APP隐私合规检测、APP整改。
agent_created	true

APP个人信息保护合规检查技能

面向公司法务、数据合规律师或合规顾问的APP个人信息保护合规评审工具包。 采用"合规事实查明 + 声明一致性核验"两阶段审查方法论，覆盖11大合规模块53检查项，法规依据通过运行时检测的MCP后端实时核验。从"业务部门提交的APP材料"到"可直接交付的合规审查报告与整改清单"，一个包闭环完成。

概述

本技能为中国移动应用（APP）个人信息保护合规评审提供系统化、结构化的检查框架。以《个人信息保护法》《网络安全法》《数据安全法》为核心依据，结合监管执法实践与行业合规标准，建立覆盖APP个人信息处理全生命周期的合规检查体系。

所有法律法规依据均经法规核验MCP后端核验，确保法规名称、文号、条款编号及现行有效性准确。详见 references/law-library.md（含24部法律法规、国家标准及团体标准）。

MCP法规核验后端（能力槽设计）

本技能的法规核验功能不绑定任何特定MCP产品。skill运行至阶段四（法规核验）时，自动扫描用户本地已连接的MCP连接器，按以下逻辑选择后端：

运行时检测逻辑：

1. 扫描已连接的MCP连接器，检测以下后端是否可用：

后端	检测方式	工具前缀
北大法宝（pkulaw）	检测 mcp__pkulaw__ 前缀工具是否可用	mcp__pkulaw__mcp-law/
华宇元典（yuandian）	检测 yuandian_ 前缀工具是否可用	yuandian_rh_fg_search 等

2. 根据检测结果选择后端：

   • 0个可用 → 报告中标注"⚠️ 未检测到法规核验MCP后端，法规依据未能实时核验，建议人工确认"，跳过MCP核验步骤
   • 1个可用 → 自动使用该后端
   • 2个均可用 → 询问用户选择使用哪一个后端进行本次核验

3. 询问用户时提供以下信息辅助决策：

后端	优势
北大法宝	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 收集以下材料：

必需材料（缺一不可）

1. APP安装包（APK文件；iOS为IPA，但本技能以Android APK静态分析为主）
2. 最新版隐私政策（完整文本，含第三方SDK清单）
3. 用户协议/服务协议
4. SDK清单（含SDK名称、所属公司、功能、收集的个人信息类型、收集目的、使用场景）
5. 权限使用清单（含权限名称、使用场景、目的说明）
6. 业务功能清单（基本功能与附加功能划分）
7. 已收集个人信息清单（双清单之一）
8. 与第三方共享个人信息清单（双清单之一）

可选材料（影响审查完整度，如不适用可跳过）

收到材料后，逐项确认是否适用。某些材料在特定场景下可能不需要，审查人员须根据APP实际情况自行判断：

9. 个性化推荐/算法推送设置说明（如APP无个性化推荐功能则不需要）
10. 账号注销流程说明（如APP无账号体系则不需要）
11. 投诉举报渠道说明（如已在隐私政策中完整说明则可不需要）
12. 适老化改造说明（如APP不属于适老化改造重点APP范围则不需要）
13. 儿童个人信息保护规则（如APP不涉及未成年人业务则不需要）
14. 数据出境情况说明（如APP不存在跨境传输则不需要）
15. 自动续费/会员订阅机制说明（如APP无自动续费功能则不需要）

提示：如某项可选材料不适用，在材料收集清单中标注"不适用"并说明原因即可，不影响审查启动。如某项材料适用但业务部门未能提供，在报告中将对应检查项标注为"材料缺失，未能完成审查"。

收到材料后，运行 scripts/material_validator.py 校验材料完整性，生成缺失项清单并提示业务部门补充。

# 校验材料完整性，输出缺失项清单与完整度评分
python scripts/material_validator.py --materials-dir /path/to/materials/

工作流程

阶段一：材料收集与校验（Day 1）

1. 向业务部门发送 assets/input-materials-template.md 材料收集清单
2. 收到材料后运行 scripts/material_validator.py 校验完整性
3. 列出缺失材料，要求业务部门在约定时限内补充

阶段二：技术核验（Day 2-3）

4. 运行 scripts/apk_analyzer.py 对APK安装包进行静态分析，提取：
   • AndroidManifest.xml中声明的全部权限
   • 安装包内识别的第三方SDK（基于包名特征库匹配）
   • 内嵌的隐私政策文本或链接
   • 应用基本信息（包名、版本号、targetSdkVersion等）
5. 将技术取证结果保存为结构化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）

6. 对照 references/checklist-full.md 中的11大模块检查项，先完成文本取证（审查文本材料）
7. 将隐私政策声明的SDK、权限、个人信息类型与APK技术取证结果逐项比对（一致性核验）
8. 将客户提供的SDK清单与APK识别的SDK逐项比对（一致性核验）
9. 将权限使用清单与AndroidManifest.xml声明的权限逐项比对（一致性核验）
10. 记录每项检查的事实发现、合规判定、风险等级

阶段四：法规依据实时核验（Day 7）—— MCP条文锚定

数据合规领域法律法规更新频繁（如《网络安全法》2025年10月已修正），skill必须在每次运行时核验所依据法规的现行有效性，避免引用已失效或已修订的条款。

核验机制：通过 references/article-anchors.md 条文锚定表，将每个检查项与具体法规条款建立程序化映射（共72个锚点）。每次运行时，先扫描已连接的MCP后端（见上方"MCP法规核验后端"能力槽设计），确定本次使用的后端后，按对应工具映射逐锚点核验。

核验流程：

1. 扫描已连接MCP连接器，检测pkulaw/yuandian可用性（0个→跳过并警告；1个→自动使用；2个→询问用户选择）
2. 加载 references/article-anchors.md，获取全部锚点清单
3. 对每个锚点，按核验频率策略执行：
   • every_run 类锚点（个保法、网安法、数据安全法、认定方法，共42个）：每次运行必核验
   • quarterly 类锚点（必要范围规定、移动互联网应用程序信息服务管理规定、164号文、524行动通知、26号文、算法推荐规定、广告管理办法、未成年人保护法、未成年人网络保护条例，共23个）：如距上次核验超90天则核验
   • annual 类锚点（GB/T国家标准，共7个）：标注"需手动核验"，因法规MCP后端通常不收录国家标准
4. 根据活跃后端调用对应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=<关键词>)

4. 将核验结果记入运行日志（JSON格式，含每个锚点的状态、核验时间、备注）
5. 对失效或已修订的依据，在报告中标注警告并调整引用条款

核验结果处理规则：

• 法规已废止 → 报告标注"⚠️ 原依据法规已废止，建议核实替代法规"
• 法规已修订 → 检索新条款，更新引用，报告标注"本报告已采用最新修订版条款"
• 法规MCP后端无法返回 → 报告标注"⚠️ 法规状态未能通过MCP核验，建议人工确认"
• 国家标准（GB/T系列）→ 报告标注"需通过全国标准信息公共服务平台人工核验"

11. 对每项不合规发现，引用 references/law-library.md 中的具体法规条款，并附条文锚点编号（如 [A014]）
12. 条文锚定表的核验结果作为报告附件，证明依据的现行有效性

阶段五：报告生成与交付（Day 8-10）

13. 运行 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

14. 生成 assets/remediation-template.md 整改清单，按优先级排序
15. 向业务部门交付：合规评审报告 + 整改清单 + 法规依据索引

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后端核验。核验方法：

1. 法规名称与文号以 references/law-library.md 为准
2. 读取 assets/mcp-backends.yaml 确认活跃后端（pkulaw或yuandian）
3. 如需确认法规是否被修改或废止，按活跃后端调用对应工具检索
4. 对于国家标准（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核验时追溯