legal-compliance git:20260901.1936886B

Immutable. This exact content is served forever at /api/v1/blob/29025d26f9f3260c.

---
name: legal-compliance
license: MIT (adapted from lawyerwangbo/legal-assistant-pro; complete terms in LICENSE.txt)
description:
  评估产品/业务是否符合中国大陆法律法规，覆盖个人信息保护法(PIPL)自查、产品上线
  合规审查、营销宣传合规审查。Use when 用户说"帮我做个合规审查""这个产品能不能
  上线""这样宣传违反广告法吗""个人信息保护法我们符合吗""PIPL合规自查"等评估
  业务/产品/宣传是否合法合规的场景。单份合同的条款风险审查用 `contract-review`；
  交易尽调用 `legal-due-diligence`。
metadata:
  origin: PIPL 14项自查清单、产品上线审查六步流与八类框架、营销合规五分类与广告法
    速查、产品功能风险评估结构，改编自 lawyerwangbo/legal-assistant-pro（MIT）；
    已移除原项目里诉讼/非诉执业场景专属的部分（案件管理、律所内部流程），
    只保留合规评估相关内容
---

# Skill: legal-compliance

评估一项业务、产品功能或一次宣传活动是否符合中国大陆现行法律法规。产出是风险
点+等级+建议，不是"能不能做"的最终拍板——重大合规决策仍需法务/律师最终把关。

## PIPL(个人信息保护法)合规自查清单

处理个人信息的产品/业务，逐项自查：

```
【PIPL 合规自查】
□ 合法性基础：处理个人信息是否有合法依据(同意/合同必需/法定义务等)
□ 告知义务：是否已按要求告知处理目的、方式、范围
□ 最小必要原则：收集的信息是否超出实现目的所必需的范围
□ 敏感个人信息单独同意：涉及敏感信息(生物识别、行踪轨迹、未成年人信息等)是否单独取得同意
□ 个人信息权利：是否支持用户查阅、复制、更正、删除、注销账号
□ 撤回同意：是否提供便捷的撤回同意渠道，撤回后是否停止相应处理
□ 委托处理：委托第三方处理个人信息是否有合规协议、是否监督受托方
□ 跨境传输：是否涉及个人信息出境，是否完成相应的安全评估/认证/标准合同备案
□ 安全措施：是否采取了与风险相适应的技术和管理安全措施
□ 合规审计：是否建立个人信息保护合规审计机制
□ 应急预案：是否制定个人信息安全事件应急预案
□ 保护负责人：处理个人信息达到规定数量的，是否指定个人信息保护负责人
□ 未成年人保护：涉及未成年人个人信息的，是否取得监护人同意并有专门保护措施
```

每一项标注状态（合规/部分合规/不合规/不适用）和依据，不合规/部分合规的项给出
具体整改建议，不要只打勾不给理由。

## 产品上线审查

新功能/新产品上线前的合规扫描：

### 六步流程

1. **获取输入**——产品需求文档、页面文案、功能说明等实际材料，不凭描述臆测
2. **理解上线内容**——搞清楚这个功能实际做什么、面向谁、收集/处理什么数据
3. **按八类框架逐一检测**（见下）
4. **遍历八类框架**——不要只挑看起来相关的几类，容易漏掉不显眼的风险
5. **校准**——结合实际业务场景判断风险等级，不是机械打勾
6. **组装输出**——按下面的双输出格式产出

### 八类审查框架

| 框架 | 检查什么 |
|---|---|
| 合同承诺 | 是否与已签合同/用户协议中的承诺矛盾 |
| 个人信息保护法(PIPL) | 见上面的14项清单 |
| 数据安全 | 数据分类分级、重要数据处理、数据出境（对应《数据安全法》） |
| 知识产权 | 是否使用他人受保护的内容、素材授权是否齐全 |
| 第三方合作 | 引入的第三方SDK/服务是否有对应的合规协议和披露 |
| 行业监管 | 所属行业是否有专门监管规定（金融、医疗、教育等特殊行业） |
| 营销宣传 | 见下面的营销合规审查 |
| AI治理 | 涉及AI生成内容/算法推荐的，是否符合相应的算法/生成式AI治理要求 |

### 双输出

- **保密备忘录**：完整的风险发现和分析，内部使用，标注保密
- **净化工单**：面向产品/研发的可执行整改清单，去掉法律分析细节，只留"要改什么"

### 来源引用分层

产出中每条依据标注来源可信度：已确认（检索到官方原文）/需验证（来自间接信息，
需要进一步核实）/需精准核实（涉及关键决策，必须找到权威原文再确定）/平台政策
（第三方平台规则而非法律本身，两者不要混为一谈）。

## 营销合规审查

### 五类广告表述分类

| 分类 | 说明 |
|---|---|
| 模糊主观 | "更好""更快"这类主观评价，风险较低 |
| 具体事实性 | 涉及具体数字/事实的表述，必须有依据支撑 |
| 比较性 | 与竞品或行业平均水平比较的表述 |
| 暗示性 | 未明说但通过语境暗示某种效果的表述 |
| 绝对性 | "最""第一""百分百""国家级"等绝对化用语 |

### 审查流程

提取宣传文案中的表述 → 按上表分类 → 逐条核实事实性表述是否有依据、比较性
表述是否有可验证的对比数据 → 对照广告法速查表检查绝对化/虚假表述。

### 广告法速查（引用前请核实现行有效条文）

| 事项 | 依据 |
|---|---|
| 禁止使用"国家级""最高级""最佳"等绝对化用语 | 广告法第九条 |
| 禁止虚假或者引人误解的宣传 | 广告法第二十八条 |
| 禁止对商品或服务作虚假或引人误解的商业宣传 | 反不正当竞争法第八条 |
| 经营者虚假宣传的消费者赔偿责任 | 消费者权益保护法第五十五条 |

这张表是审查起点，正式出具意见前用 `legal-search` 技能核实条文现行有效版本
（法律会修订，条号可能变化）。

## 产品功能风险评估

对单个高风险功能（新模式、可能触发监管关注、团队内部有担忧）单独出一份评估：

**触发场景**：全新的商业模式、涉及资金/数据的关键流程、法务主动要求评估、
监管近期有相关关注动向、内部团队对合规性有疑虑。

**六段结构**：
1. 评估对象——功能是什么，怎么运作
2. 风险点（2-5个，不贪多但要讲透）
3. 监管环境——现行相关监管规定和趋势
4. 先例——是否有同类产品/功能被处罚或整改的案例（有真实来源才引用，参考
   `legal-search` 的案例真实性规则）
5. 可选方案——不同风险容忍度对应的产品方案
6. 建议——推荐方案及理由

篇幅控制在2-4页，独立成文，不要塞进更大的报告里稀释重点。

## 边界

- 给出的是风险识别和整改建议，不是"合规/不合规"的终局认定——重大合规决策
  （尤其涉及监管处罚风险、跨境数据传输方案）需要专业律师或合规团队最终把关。
- 不臆测具体条文的现行文本，条文核实交给 `legal-search`。
- 单份合同的条款审查用 `contract-review`；面向交易/投资的批量文档尽调用
  `legal-due-diligence`。