knowledge-work-plugins 合规检查技能实战指南：从法规识别到 DPA 审查与数据主体请求处理
【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins
导读
本文围绕开源仓库 knowledge-work-plugins 中 legal 插件的compliance-check技能展开，系统讲解如何对拟推出的产品功能、营销活动或商业举措进行合规检查：识别适用的法规、所需审批与风险区域。读完本文，你将掌握标准合规检查报告的完整结构、GDPR / CCPA-CPRA 等主要隐私法规的核心义务、DPA（数据处理协议）逐条审查清单、数据主体请求的完整处理流程，以及监管动态监控与升级判断方法，可直接用于企业法务（In-House Legal）日常工作。
重要声明：该技能用于辅助法律工作流，不构成法律意见。合规评估结论必须由合格的法律专业人士复核；法规要求变化频繁，始终应以权威来源核验最新要求。
一、技能定位与调用方式
compliance-check是 legal 插件 中面向法务团队的核心技能之一。在 SKILL.md 的 frontmatter 中，其触发条件被精确定义为：
- 推出的功能涉及个人数据处理时；
- 市场或产品团队提出具有监管含义的方案时；
- 需要了解落地前适用哪些审批与司法辖区要求时。
其调用方式为一个斜杠命令：
/compliance-check $ARGUMENTS参数即为待检查的行动或举措描述（frontmatter 中argument-hint标注为"<action or initiative to check>"）。与 legal/README.md 中列出的contract-review、triage-nda等技能不同，compliance-check 的输入通常不是文档，而是一个商业行动或产品功能的自然语言描述。
技能文件开头的提示还指向了 CONNECTORS.md：该文件用~~category这类占位符代表用户连接的具体工具（如~~cloud storage可能对应 Box、Egnyte 或其他提供 MCP 服务器的存储服务），插件本身是工具无关（tool-agnostic）的，法务团队可按需接入 CLM、CRM、邮箱、云存储等系统以支撑合规检查所需的信息检索。
二、输入要求：描述越具体，检查越精准
运行/compliance-check前，用户需要描述"打算做什么"。SKILL.md 给出的示例涵盖了典型的高风险场景：
- "We want to launch a referral program with cash rewards"（推荐返现计划，涉及激励与消费者权益）
- "We're adding biometric authentication to our mobile app"（生物识别认证，涉及特殊类别数据）
- "We need to process EU customer data in our US data center"（跨境数据传输）
- "Marketing wants to use customer testimonials in ads"（客户推荐语用于广告，涉及数据使用目的与同意）
在本文末尾的"Tips"中，SKILL.md 进一步强调了三要素：具体（"我们要给所有用户发邮件"优于"营销活动"）、地理范围（合规要求因司法辖区而异）、数据类型（涉及哪些个人数据——这决定了大多数合规要求）。这也是合规检查结果质量的前提：输入信息不足时，输出只能是基于假设的初步评估。
三、标准输出结构：一份可直接交付的合规检查报告
compliance-check的产出是一份结构化 Markdown 报告，SKILL.md 给出了完整模板。各章节及其作用如下：
3.1 总览（Summary）
以三档结论快速定性：Proceed（可推进）/ Proceed with conditions（有条件推进）/ Requires further review（需进一步审查）。这与 legal-risk-assessment 中 GREEN / YELLOW / RED 的风险分级思路一脉相承，但更侧重"行动是否可以继续"的决策结论。
3.2 适用法规与政策表
| Regulation/Policy | Relevance | Key Requirements |
|---|---|---|
| [GDPR / CCPA / HIPAA / etc.] | [How it applies] | [What you need to do] |
表格要求逐项列出每部法规对当前举措的适用方式与必须采取的动作，避免只罗列法规名称而不落到操作。
3.3 要求清单表
| # | Requirement | Status | Action Needed |
|---|---|---|---|
| 1 | [Requirement] | [Met / Not Met / Unknown] | [What to do] |
状态三档明确：已满足、未满足、未知。Unknown档的存在意味着报告必须诚实标注信息缺口，而不是默认假设合规。
3.4 风险区域表
| Risk | Severity | Mitigation |
|---|---|---|
| [Risk] | [High/Med/Low] | [How to address] |
风险需给出严重度分级与缓解措施。如需更精细的风险量化，可结合 legal-risk-assessment 的"严重度 × 可能性"评分矩阵（1–25 分对应 GREEN/YELLOW/ORANGE/RED）做后续深化。
3.5 建议行动（Recommended Actions）
按优先级列出 1–3 条行动项，第一条为最重要动作。
3.6 所需审批表
| Approver | Why | Status |
|---|---|---|
| [Person/Team] | [Reason] | [Pending] |
明确审批人、审批原因与当前状态，为举措推进提供授权路径。
3.7 建议进一步审查（Further Review Recommended）
标注需要外部律师（outside counsel）或专家审查的领域——这既是对输出的免责保护，也符合该插件"AI 辅助、律师复核"的定位（见 legal/README.md 顶部声明）。
四、隐私法规全景：GDPR 与 CCPA/CPRA 核心义务
SKILL.md 用大篇幅梳理了合规检查必须对照的两大支柱性法规，以及需要持续监控的其他辖区法规。
4.1 GDPR（欧盟通用数据保护条例）
适用范围：适用于对欧盟/欧洲经济区（EU/EEA）境内个人数据的处理，无论处理组织位于何处——这正是"在美国数据中心处理欧盟客户数据"场景会触发 GDPR 的原因。
法务团队关键义务清单：
- 合法性基础（Lawful basis）：为每项处理活动识别并记录合法性基础（同意、合同、合法利益、法定义务、重大利益、公共任务）。
- 数据主体权利：在 30 天内响应访问、更正、删除、可携权、限制处理与反对等请求（复杂请求可延长 60 天）。
- 数据保护影响评估（DPIA）：对可能给个人带来高风险的处理活动为强制要求。
- 违约通知：意识到个人数据泄露后 72 小时内通知监管机构；若存在高风险，须及时通知受影响个人。
- 处理活动记录（Article 30）：维护第 30 条要求的处理活动记录。
- 国际传输：确保向欧洲经济区以外的传输具备适当保障（SCCs 标准合同条款、充分性认定、BCRs 约束性公司规则）。
- DPO 任命：符合条件时（公共机构、大规模特殊类别数据处理、大规模系统性监控）须任命数据保护官。
企业法务常见触点：审阅供应商 DPA 的 GDPR 合规性、就"隐私设计（privacy by design）"要求向产品团队提供建议、回应监管机构问询、管理跨境数据转移机制、审阅同意机制与隐私通知。
4.2 CCPA / CPRA（加州消费者隐私法 / 加州隐私权法）
适用范围：适用于收集加州居民个人信息，且满足收入、数据量或数据出售门槛的企业。
核心义务：
- 知情权（Right to know）：消费者可请求披露被收集、使用和共享的个人信息。
- 删除权（Right to delete）：消费者可请求删除其个人信息。
- 选择退出权（Right to opt-out）：消费者可退出个人信息的出售或共享。
- 更正权（Right to correct）：消费者可请求更正不准确的个人信息（CPRA 新增）。
- 限制敏感个人信息使用（Right to limit use of sensitive PI）：消费者可将敏感个人信息的使用限于特定目的（CPRA 新增）。
- 非歧视原则：不得歧视行使权利的消费者。
- 隐私通知：在收集时或收集前提供隐私通知，说明收集的个人信息类别与目的。
- 服务提供商协议：与服务提供商的合同须将个人信息使用限定于指定的业务目的。
响应时间线：10 个工作日内确认收到；45 个日历日内实质响应（经通知可延长 45 天）。
4.3 其他需持续监控的法规
| Regulation | Jurisdiction | Key Differentiators |
|---|---|---|
| LGPD（巴西） | 巴西 | 与 GDPR 相似；须任命 DPO；国家数据保护局（ANPD）执法 |
| POPIA（南非） | 南非 | 信息监管局监督；处理须注册 |
| PIPEDA（加拿大） | 加拿大（联邦） | 以同意为基础；OPC 监督；正进行现代化修订 |
| PDPA（新加坡） | 新加坡 | 谢绝来电登记册；强制性违约通知；PDPC 执法 |
| Privacy Act（澳大利亚） | 澳大利亚 | 澳大利亚隐私原则（APPs）；可通知数据泄露机制 |
| PIPL（中国） | 中国 | 严格的跨境传输规则；数据本地化要求；CAC 监管 |
| UK GDPR | 英国 | 脱欧后的英国版本；ICO 监管；与欧盟 GDPR 类似并含英国特定充分性安排 |
这张表格说明合规检查天然是"多辖区"工作：同一举措可能同时落入欧盟、加州、巴西等多个框架，且各框架的时间线、义务与执法机构均不同，这正是 legal/README.md 强调"默认示例反映美国法立场（特拉华、纽约、加州），在其他法域使用前必须自定义 playbook"的原因。
五、DPA 审查清单：审阅数据处理协议的标准动作
当合规检查涉及与供应商/处理者的数据共享时，SKILL.md 提供了完整的 DPA（Data Processing Agreement / Data Processing Addendum）审查清单。
5.1 GDPR 第 28 条必备要素
审查 DPA 时，以下要素必须明确界定：
- 处理主题与期限（Subject matter and duration）：处理的范围与期限定义清晰；
- 处理性质与目的（Nature and purpose）：具体描述处理内容与原因；
- 个人数据类型（Type of personal data）：被处理的个人数据类别；
- 数据主体类别（Categories of data subjects）：被处理者为何人；
- 控制者义务与权利（Controller obligations and rights）：控制者的指示与监督权。
5.2 处理者（Processor）义务逐项核对
- 仅按书面指示处理：处理者承诺仅按控制者指示处理（法定要求除外）；
- 保密性：被授权处理的人员已承诺保密；
- 安全措施：描述适当的技术与组织措施（引用第 32 条）；
- 子处理者要求：
- 需书面授权（一般授权或特定授权）；
- 若为一般授权：变更时须通知并给予反对机会；
- 子处理者通过书面协议受相同义务约束；
- 处理者对子处理者的履约负责；
- 数据主体权利协助：处理者协助控制者响应数据主体请求；
- 安全与违约协助：处理者协助履行安全义务、违约通知、DPIA 及事先咨询；
- 删除或返还：终止时按控制者选择删除或返还全部个人数据，并删除现有副本（法定留存要求除外）；
- 审计权：控制者有权进行审计与检查（或接受第三方审计报告）；
- 违约通知：处理者应及时（理想为 24–48 小时内）通知控制者个人数据泄露，以确保控制者满足 72 小时监管期限。
5.3 国际传输核对项
- 已识别传输机制：SCCs、充分性认定、BCRs 或其他有效机制；
- SCCs 版本：如适用，使用现行欧盟 SCCs（2021 年 6 月版）；
- 正确模块：选择适当的 SCC 模块（C2P、C2C、P2P、P2C）；
- 传输影响评估：向无充分性认定的国家传输时须完成；
- 补充措施：针对传输影响评估发现缺口的技术、组织或合同措施；
- 英国附录：如涉及英国个人数据，须包含英国国际数据传输附录。
5.4 实务考虑项
- 责任条款与主服务协议一致或不冲突；
- DPA 期限与主服务协议一致；
- 处理地点已明确且可接受；
- 明确具体安全标准或认证要求（SOC 2、ISO 27001 等）；
- 数据处理活动具备充分的保险覆盖。
5.5 常见 DPA 问题速查表
| Issue | Risk | Standard Position |
|---|---|---|
| 无通知的概括性子处理者授权 | 失去对处理链的控制 | 要求通知并保留反对权 |
| 违约通知时限超过 72 小时 | 可能延误法定监管通知 | 要求 24–48 小时内通知 |
| 无审计权（或仅能依赖第三方报告） | 无法核验合规 | 接受 SOC 2 Type II + 有因审计权 |
| 未规定数据删除时限 | 数据被无限期保留 | 要求终止后 30–90 天内删除 |
| 未指定数据处理地点 | 数据可能在任何地方处理 | 要求披露处理地点 |
| SCCs 过时 | 传输机制无效 | 要求现行欧盟 SCCs（2021 版） |
这张表在合规检查中的价值在于：它把常见的合同谈判症结固化为"风险—标准立场"的对照，使 AI 输出与法务判断可对齐、可引用。
六、数据主体请求（DSR）处理全流程
compliance-check评估的举措一旦涉及个人数据，往往随之产生数据主体请求的合规义务。SKILL.md 为此提供了从接受到响应的完整流程。
6.1 请求受理（Request Intake）
- 识别请求类型：访问（Access，获取个人数据副本）、更正（Rectification）、删除/擦除（Erasure/deletion，"被遗忘权"）、限制处理（Restriction of processing）、数据可携权（Data portability，结构化机器可读格式）、反对处理（Objection to processing）、退出出售/共享（Opt-out of sale/sharing，CCPA/CPRA）、限制敏感个人信息使用（CPRA）。
- 识别适用法规：数据主体位于何处？基于组织的存在地与活动适用哪些法律？具体要求与时间线为何？
- 核验身份：确认请求人身份；核验措施应与数据敏感性成比例；不得要求过度文件。
- 记录请求：收到日期、请求类型、请求人身份、适用法规、响应截止日期、指定处理人。
6.2 响应时间线对照表
| Regulation | Initial Acknowledgment | Substantive Response | Extension |
|---|---|---|---|
| GDPR | 未明确（最佳实践：及时） | 30 天 | +60 天（经通知） |
| CCPA/CPRA | 10 个工作日 | 45 个日历日 | +45 天（经通知） |
| UK GDPR | 未明确（最佳实践：及时） | 30 天 | +60 天（经通知） |
| LGPD | 未明确 | 15 天 | 延长受限 |
这张表提醒合规人员：跨辖区处理请求时，截止日期必须按"最严格适用规则"管理，不能混用。
6.3 豁免与例外（Exemptions and Exceptions）
履行请求前须检查是否适用豁免。跨法规常见豁免包括：法律索赔的抗辩或确立、要求留存的法定义务、公共利益或官方权力、表达与信息自由（针对删除请求）、公共利益或科学/历史研究的归档。组织特定考量包括：诉讼保全（litigation hold）下的数据不得删除、财务记录与雇佣记录等类别的法定强制留存期、履行请求可能损害第三方权利的情形。
6.4 响应流程
- 跨系统收集请求人的全部个人数据；
- 适用豁免并记录依据；
- 准备响应：履行请求，或解释（全部或部分）无法履行的原因；
- 若拒绝（全部或部分）：援引具体的法律依据；
- 告知请求人向监管机构投诉的权利；
- 记录响应内容并留存请求与响应的档案。
七、监管监控基础：保持法规态势感知
合规检查不是一次性动作。SKILL.md 将"监管监控"列为持续义务，并给出方法与升级标准。
监控内容：
- 监管指引：监管机构（ICO、CNIL、FTC、各州总检察长等）新发布或更新的指引；
- 执法行动：罚款、命令与和解，这些信号反映监管优先方向；
- 立法变化：新隐私法、现行法律修正案、实施细则；
- 行业标准：ISO 27001、SOC 2、NIST 框架及行业特定要求的更新；
- 跨境传输动态：充分性认定、SCC 更新、数据本地化要求。
监控方法：订阅监管机构通讯（新闻简报、RSS、官方公告）；跟进相关法律出版物对新动态的分析；查看行业协会更新的行业特定指引；维护监管日历记录已知的截止日期、生效日与合规里程碑；就影响组织处理活动的重大进展向法务团队汇报。
升级标准（升级至高级律师或管理层）：新法规/指引直接影响组织核心业务；所在行业的执法行动预示监管审查趋严；合规截止日临近且需要组织层面调整；组织依赖的传输机制被质疑或失效；监管机构对组织发起问询或调查。
八、使用技巧与最佳实践
SKILL.md 结尾的 Tips 是输入质量的三大原则，也是本技能能否产出有效结果的直接决定因素：
- Be specific（具体化）——"We want to email all our users"优于"marketing campaign"；
- Include the geography（说明地理范围）——合规要求因司法辖区而异；
- Mention the data（提及数据）——涉及哪些个人数据？这驱动大多数合规要求。
九、与插件体系的协作方式
compliance-check并非孤立技能，它与 legal 插件 的其他能力形成工作流闭环：
- 输入侧：检查对象常来自业务团队提议，可通过 CONNECTORS.md 接入的邮箱、Slack/Teams 聊天、项目跟踪工具（Jira/Confluence）收集举措背景；
- 深化侧：报告中的"风险区域"可对接 legal-risk-assessment 的严重度 × 可能性矩阵，将 High/Med/Low 细化为 1–25 分的量化评分与 GREEN/YELLOW/ORANGE/RED 分级；
- 输出侧：审批与行动项可通过项目跟踪工具流转，形成"检查—审批—跟踪"的完整闭环；
- 配置侧：与插件的其他技能一致，legal/README.md 建议法务团队通过本地设置文件（Cowork 下为共享文件夹中的
legal.local.md，Claude Code 下为项目.claude/目录）自定义本组织的标准立场、可接受范围与升级触发条件——合规检查的结论基准（如可接受的责任上限、DPA 标准条款）都应来自这套自定义 playbook。
结语
compliance-check将法务团队面对新举措时的散点问题——适用哪些法规、需要哪些审批、风险在哪里、如何缓解——固化为可复现、可审计的结构化流程。其价值不在于替代律师判断，而在于提供一份覆盖 GDPR、CCPA/CPRA、DPA 审查、数据主体请求与监管监控的系统化检查框架，让 AI 辅助产出与人类专家复核高效衔接。实际使用时，务必牢记：任何结论都应经合格法律专业人士复核，并依据 legal/README.md 的指引针对你的司法辖区定制组织 playbook。
【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
