Worker 输出：case-03 数据合规扫描 Brief
运行实例：worker-case03（全新上下文独立 agent，2026-08-23） 输入：
worker-inputs/case-03.md（无泄露版本）
收到素材。我已按 legal-skill-alignment 的工作流程处理：先做路径判定与安全预检，再厘清素材、补全五问，最后产出 Brief。以下是完整结果。
前置判定结论
路径判定：您提供了历史报告样本 + 内部 SOP，走有素材路径（多分类厘清）。场景属于法律合规领域（数据合规扫描），本 Skill 正常触发。
安全预检：
- 未检出身份证号、手机号、自然人姓名等高风险敏感信息；样本企业名已为"XX 社交科技有限公司"占位形式，视为已脱敏。
- 提示两点（仅提示，不改写您的原文件）：样本中"日活 50 万""阿里云华东节点"属客户业务与基础设施信息，建议后续模板中以"日活 N 万""XX 云 XX 节点"等占位符表达，避免个案客户信息沉淀进通用 Skill。
- 本次处理全程本地，不外传、不联网检索。
关键缺口预告：素材中的法源（四部法规 + 《App 违法违规收集使用个人信息行为认定方法》）只有名称和条号，无法源原文或权威出处。本 Skill 产出的报告含合规整改建议（属具体法律建议），因此该项登记为 blocker，Brief 状态为"结构完整、暂不可交接"——补齐法源原文即可解除。
素材厘清摘要：
| 素材 | 分类 | 提取内容 |
|---|---|---|
| 素材 1（历史报告节选） | sample（成品文书） | 报告结构骨架（四大扫描维度）、13 项检查项与风险判定实例、风格特征（表格化/三色/法条精确到条）、法源引用清单（仅条号） |
| 素材 2（内部 SOP） | sop（主）+ rules（部分） | 8 步主流程、输出规范（风险等级 + 整改建议 + 期限）、风格规则清单 |
| 法源原文（authorities） | 缺失 | 0 份——仅有样本内引用，无原文，构成 blocker |
单样本局限：仅 1 份节选样本，可提取结构骨架与风格，但决策分支、异常路径、完整章节顺序可能不完整，已在待确认清单标注。
Skill 编译请求：App 数据合规扫描报告
由 legal-skill-alignment 对齐产出，遵循 legal-skill-brief/v1 规范（question-set/v1 五问）。 下游消费者：通用
skill-creator或legal-skill-creator。 交接状态：structurally_complete = true，handoff_ready = false（含 1 项 blocker），不建议下游直接编译；补齐法源原文出处后即可交接。
一、上下文元数据
- skill_family：
app-data-compliance-scan - jurisdiction：CN
- stage：
post_launch（运营中 App 的合规体检；样本为日活 50 万的已上线产品） - operator：律所合规团队律师 / 合规专员（推断，待确认）
- represented_party：被评估的 App 运营公司（客户，被监管方立场）（推断，待确认）
- output_audience：客户公司数据合规负责人（据报告抬头推断）
- doc_type：
compliance-report - tags：[data-compliance, personal-information-protection, app-scan, social-app, third-party-sdk]
二、五问要素（question-set/v1）
1. 输入什么（Inputs）
必要输入：
- 被评估 App 基本信息：App 名称（脱敏占位）、类型与业务模式、用户规模、平台（iOS/Android）
- App 收集的个人信息类型清单、申请的系统权限清单
- 使用的第三方 SDK 清单（名称、类型、收集的数据）
- 隐私政策全文（现行生效版本）
- 同意机制的呈现方式说明（注册/首次运行流程、弹窗截图或描述）
可选输入：
- 数据存储方案说明（存储位置、加密措施、保留期限策略）
- 用户权利实现渠道说明（注销/查询/更正/删除/投诉的入口与流程）
- 与第三方 SDK 供应商的数据处理协议样本
- 客户已有的数据安全管理制度文件
信息来源：客户提供的资料 + 扫描执行过程中的核验记录（具体采集方式——客户问卷 / 访谈 / App 实测 / 技术检测——素材未明确，待确认）
2. 输出什么（Outputs）
主要产出：App 数据合规扫描报告
格式要求：
- 抬头：致 XX 公司数据合规负责人
- 结构：抬头 → 被评估企业概况 → 四大扫描维度逐一呈现 → 法律依据 → 整改建议（含优先级与期限）
- 四大扫描维度（源自样本骨架）：一、个人信息收集；二、数据存储与安全；三、用户权利保障；四、第三方数据共享
- 检查项表格化呈现，列结构：检查项 / 结果（合规 / 部分合规 / 不合规）/ 风险等级（高 / 中 / 低）
- 风险等级三色标注（红 / 黄 / 绿）
- 法条引用精确到条
- 整改建议必须含优先级和整改期限
- 语气：专业、建设性
质量标准：每项"不合规/部分合规"结论均附法条依据（精确到条）；同类检查项在不同项目中风险等级判定一致；整改建议可执行、有期限；报告结构在不同项目中统一
产出形态：mixed（表格为主 + 正文叙述）
3. 处理逻辑（Workflow）
主流程（源自 SOP 8 步）：
- 产品功能梳理：确认 App 类型、收集的数据类型、使用的第三方 SDK
- 决策点：App 类型与业务模式识别结果 → 决定后续检查项范围与"必要权限"判断基准（映射基准素材未提供，待补）
- 隐私政策审查：对照《个人信息保护法》第 17 条，逐项核对隐私政策覆盖度
- 权限合理性审查：按"最小必要"原则逐项检查权限必要性
- 决策点：权限对应功能是否核心必要 → 必要 = 合规；非必要 = 不合规（高风险）
- 同意机制检查：确认是否获取有效同意
- 决策点：默认勾选 / 一揽子同意 → 不合规；敏感个人信息（如位置）是否单独同意 → 未单独取得 = 不合规（高风险）
- 数据安全措施检查：加密、脱敏、访问控制、日志审计；含数据保留期限与安全管理制度
- 分支示例（源自样本）：传输加密但存储未加密 → "部分合规"（中风险）
- 用户权利实现检查：注销、查询、更正、删除、投诉渠道
- 第三方管理检查：SDK 清单披露、数据处理协议签订情况
- 输出扫描报告：风险等级（高/中/低）+ 整改建议 + 整改期限
- 质量检查点：高风险结论与整改建议须经执业律师复核后方可交付
异常路径：
- 部分合规情形（措施存在但不完整）→ 单列"部分合规"并给出补足性整改建议
- 客户无法提供某项事实材料（如 SDK 清单不全）→ 该检查项标注"信息不足、无法判定"，不臆测结论（素材未覆盖此场景，为补全建议，待团队确认）
4. 向谁交付（Context.Delivery）
operator：律所合规团队律师 / 合规专员（推断依据：您提到"我在律所的合规团队""让团队按统一标准出报告"——待确认单一主要角色）
represented_party：被评估的 App 运营公司（客户，被监管方立场）。推断依据：扫描服务是受客户委托、以建设性整改为导向，站在企业合规侧而非监管侧。
output_audience：客户公司数据合规负责人（依据：样本抬头"致 XX 公司数据合规负责人"）。是否存在第二读者（客户法务、管理层、监管报送版本）待确认。
触发场景：客户委托的运营中 App 数据合规体检；是否延伸用于上线前合规审查、监管问询应对，待确认。
语气基调：专业、建设性（素材明示）
防错核对（v1.0.4 强制）：(a) 三子项均非空；(b) represented_party 为被评估企业（当事人），未误填读者类角色——数据合规负责人属 output_audience；(c) operator（律所合规团队）与 output_audience（客户方）未混淆。三子项信号在素材中一致（抬头、服务模式、SOP 交付对象互印证）。
5. 需要哪些知识支撑（Knowledge Base）
法律依据：
法源原文缺失：以下条目均 unverified，待用户补充权威出处后升级。 素材仅提供法规名称与条号引用，无法源原文、施行日期或链接，不得据此编写确定性法律结论。
| 法条 / 司法解释 | jurisdiction | effective_date | verification_status | source_url / source_file | verified_by | verified_at | version_as_of | 说明 |
|---|---|---|---|---|---|---|---|---|
| 《个人信息保护法》第 6/7/13/14/15/17/23/24/29/30/39/47 条 | CN | unverified | unverified | unverified | unverified | unverified | unverified | 样本引用条号；仅名称+条号，待补原文、施行日与现行版本 |
| 《数据安全法》第 21/27/30 条 | CN | unverified | unverified | unverified | unverified | unverified | unverified | 同上 |
| 《网络安全法》第 41/42/43 条 | CN | unverified | unverified | unverified | unverified | unverified | unverified | 同上；另须确认所引为最新施行版本 |
| 《App 违法违规收集使用个人信息行为认定方法》 | CN | unverified | unverified | unverified | unverified | unverified | unverified | 仅文件名称；待补发文字号、全文与现行有效性 |
范本来源：历史数据合规扫描报告（素材 1，节选、已脱敏）+ 内部 App 数据合规扫描 SOP（素材 2）
风险清单（源自样本 13 项检查项归纳）：未获有效同意（默认勾选）/ 收集非必要信息（通讯录、相册）/ 敏感信息未单独同意 / 无账号注销入口 / 第三方 SDK 未披露 / 无数据处理协议（部分供应商）/ 存储未加密 / 无数据删除策略 / 无书面数据安全制度 / 无客服响应通道 / 强制个性化推荐 / 隐私政策覆盖不足
风格偏好：检查项表格化；风险等级三色标注（红/黄/绿）；法条引用精确到条；整改建议含优先级和期限；抬头"致 XX 公司数据合规负责人"；语气专业、建设性
三、规则引擎
阈值配置：
| 阈值名 | 数值 | 触发动作 | source |
|---|---|---|---|
| 风险等级映射 | 高 / 中 / 低（具体判定标准素材未定义，见下方判断标准表） | 三色标注 + 分级整改建议 | SOP 输出规范 + sample-001 反推（待团队确认） |
| 整改期限 | 按风险等级设定（具体时长标准素材未提供） | 报告中列明 | SOP 提及输出项；标准 unverified |
判断标准（均为单样本反推，不得未经确认直接通用化）：
| 标准名 | 判定逻辑 | 触发条件 | source |
|---|---|---|---|
| 无效同意 | 默认勾选/一揽子同意 → 不合规（高） | 同意机制检查 | sample-001 反推 |
| 非必要收集 | 收集与核心功能无关的权限/信息 → 不合规（高） | 权限合理性审查 | sample-001 反推 |
| 敏感信息未单独同意 | 位置等敏感信息无单独弹窗 → 不合规（高） | 同意机制检查 | sample-001 反推 |
| 核心权利缺失 | 无注销入口 → 不合规（高） | 用户权利检查 | sample-001 反推 |
| SDK 未披露 | 隐私政策未列明第三方 SDK → 不合规（高） | 第三方管理检查 | sample-001 反推 |
| 加密不完整 | 传输加密但存储未加密 → 部分合规（中） | 数据安全检查 | sample-001 反推 |
四、素材溯源
| 素材类型 | 数量 | 来源 | quality | 用途 |
|---|---|---|---|---|
| sample（成品文书） | 1（节选） | 历史数据合规扫描报告（企业名已占位脱敏） | silver（内部交付物但为节选、未标注是否经律师审核） | 结构骨架 / 风格特征 / 风险清单 / 法条条号 |
| sop（流程规则） | 1 | 内部 App 数据合规扫描 SOP（8 步） | silver（在用流程，未标注审核状态） | 主流程 / 决策点 / 输出规范 |
| rules（规则包，与 SOP 同源） | 1 | 素材 2 风格特征清单 | silver | 输出格式与风格规则 |
| authorities（法源原文） | 0 | 仅有样本内名称+条号引用 | —（缺失，构成 blocker） | 待补 |
单样本提示：仅 1 份节选样本，厘清出的报告结构与风险判定模式可能不完整，决策分支基于单样本逆推。
五、安全与脱敏说明
敏感材料处理：
- 已识别敏感信息：无身份证号/手机号/自然人姓名等高风险项；企业名已为"XX"占位；样本含客户业务数据（日活、云节点），建议模板化时用占位符
- 脱敏状态：已脱敏（用户提供时即以占位形式）
- 脱敏责任：用户提供时已脱敏；Brief 内继续使用占位表述
外传策略：
- 是否需要外部检索：否
- 是否上传外部服务：否
- 数据留存策略：本地处理，一次性使用
高风险结论复核：
- 是否涉及最终法律结论：是（含合规整改建议，属具体法律建议）
- 是否需要执业律师复核：是——高风险结论与整改建议（尤其涉及监管报送的）交付前须经执业律师复核签发
六、待确认清单
状态判定
- structurally_complete: true（五问齐全，缺口已如实标注）
- handoff_ready: false（存在 1 项 blocker）
- blocker 数：1
- warning 数：10
阻塞交接缺口（blocker）
- 关键法源原文缺失：Brief 会产出合规整改建议（具体法律建议），但四部法规 + 《认定方法》仅有名称/条号，无任何 source_url 或 source_file。补充方式：提供权威出处链接或本地法条库原文，并逐条确认现行有效版本与施行日期 — type: blocker
可带警告交接缺口（warning）
- operator 推断（律所合规团队律师/合规专员）：依据用户自述推断，需确认主要操作角色 — type: warning
- represented_party 推断（被评估 App 公司/被监管方立场）：依据服务模式与语气推断，需确认 — type: warning
- output_audience（客户数据合规负责人）：据抬头推断，需复述确认；是否有第二读者待明确 — type: warning
- 风险等级判定规则：高/中/低映射标准素材未定义，判断标准表全部为单样本反推，需团队共识 — type: warning
- 整改期限与优先级标准：SOP 要求输出但未给具体时长/标注规则 — type: warning
- 事实采集方式未明确：权限清单、SDK 清单、存储方案等如何获取（问卷/访谈/实测/技术检测），影响输入定义 — type: warning
- 单样本+节选：完整报告章节顺序（是否有总体结论/合规评分/概述页）未确认；建议补 2-3 份完整脱敏样本 — type: warning
- 法源时效未验证：所引版本是否现行有效、施行日期均待核（含《网络安全法》近年修订情况须确认引用版本）— type: warning
- 适用范围边界：Skill 限定社交类 App 还是泛化各类型 App；"最小必要"判断是否需按 App 类型内置基准 — type: warning
- 法源覆盖度：素材法源清单外是否还需引用其他配套规范（如必要个人信息范围类规定、个人信息安全类国家标准）——如需纳入请提供名称与原文 — type: warning
需要您确认的问题（按重要性排序）
- （唯一 blocker）法源原文：能否提供四部法规 + 《App 违法违规收集使用个人信息行为认定方法》的权威出处（官网链接或您所内法条库路径），并确认所引版本的施行日期、是否现行有效？补齐这一项，Brief 即可交接编译。
- 这个 Skill 做好后，主要由谁直接操作？（合规团队律师 / 律师助理 / 合规专员 / 配合 AI 批量处理）
- 确认交付关系：报告站在被评估 App 公司（客户）立场、最终交给客户数据合规负责人——对吗？是否还有第二读者（客户法务、管理层、或需出监管报送版）？
- 风险等级的高/中/低判定标准，团队是否已有共识版本？（素材未定义，我在规则引擎里放的是单样本反推稿，需您校准）
- 整改期限：高/中/低风险分别给多长整改期限？优先级用什么方式标注（如 P0/P1/P2）？
- 扫描所需的事实信息（权限清单、SDK 清单、存储方案、注销入口等）通过什么方式采集？（客户问卷 / 访谈 / App 实测 / 技术检测工具）
- Skill 的适用范围：只服务社交类 App，还是泛化到其他类型？不同类型 App 的"必要权限/必要个人信息"基准如何内置？
- 能否再提供 2-3 份完整历史报告（脱敏后）？用于确认完整章节结构和不同情形下的输出差异——目前只有 1 份节选。
- 除素材中四部法规 + 《认定方法》外，实务中是否还引用其他配套规范？如需纳入请给名称和原文。
- 律师复核节点：高风险结论与整改建议交付前，是否必须经执业律师复核签发？（我按"必须"写入了质量检查点，请确认）
下一步
这份 Brief 已经把您的两类素材结构化完毕。等您补齐第 1 项法源原文（并顺手回答其余问题），我可以直接把这份 Brief 交给：
- 通用
skill-creator，或 legal-skill-creator（法律领域编排器）
由下游编译生成正式的 SKILL.md / references / scripts——那一步不在本次对齐范围内。您也可以先回答部分问题，我更新 Brief 后再交接。