关于 regulatory-compliance
用于评估系统、流程、界面和数据处理协议的合规技能,覆盖隐私与无障碍要求。输出 PASS、CONDITIONAL 或 FAIL 结论,并列出分级发现和整改任务。
主要功能
- 01GDPR 与 CCPA 评估
- 02隐私设计审查
- 03ADA 与 WCAG 无障碍审计
- 04数据处理协议验证
- 05法规监测指导
- 06结构化结论与整改任务
适用场景
- 01评估处理个人数据的系统
- 02审查供应商协议与 DPA
- 03审计面向公众的界面无障碍性
- 04在 CI 流水线加入合规检查
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ oimiragieo/ agent-studio --skill regulatory-compliance安装后在 Claude Code 中输入/regulatory-compliance确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
commands/regulatory-compliance.mdhooks/post-execute.cjspre-execute.cjsreferences/research-requirements.mdrules/regulatory-compliance.mdschemas/input.schema.jsonoutput.schema.jsonscripts/main.cjstemplates/implementation-template.md详细介绍
监管合规技能
概述
根据主要监管框架评估系统、流程和制品:
- GDPR/CCPA — 符合欧盟和加利福尼亚州/美国各州的数据隐私法律
- Privacy-by-Design — 按照 Ann Cavoukian 的 7 项原则,主动将隐私保护融入设计
- ADA/WCAG — 符合 ADA 和 WCAG 2.1/2.2 AA 标准的 Web 和软件无障碍要求
- DPA 验证 — 检查数据处理协议的完整性和正确性
- 监管监控 — 提供跨司法管辖区跟踪监管变化的指导
输出结果分为 PASS / CONDITIONAL / FAIL,并包含按严重程度分级的发现和可执行的整改任务。
适用场景
- 部署任何收集、处理或存储个人数据的功能之前
- 在涉及 PII 或用户数据的系统架构评审期间
- 验证第三方供应商协议和 DPA 时
- 在欧盟、加利福尼亚州或任何实施隐私法的司法管辖区推出产品之前
- 审计面向公众的界面是否符合无障碍要求时
- 将其作为数据管道和 API 的 CI 合规门禁
铁律
- 绝不在合规不完整时报告 PASS — 任何项目不合格,结果都应为 CONDITIONAL 或 FAIL;部分合规会掩盖违规行为。
- 始终附上由具体责任 Agent 执行的整改任务 — 含糊的发现无法带来修复;每项 FAIL/CONDITIONAL 都必须说明由谁、如何修复。
- 绝不跳过多司法管辖区检查 — GDPR、CCPA 和 20 多部美国各州法律可能同时适用;必须明确记录范围。
- 始终在设计阶段验证隐私设计 — 部署后再补充隐私保护,成本会高得多,效果也更差。
- 绝不将无障碍要求视为可选项 — ADA/WCAG 合规面临现实的诉讼风险(2025 年上半年 ADA 诉讼增加 37%);必须验证所有公开界面。
- 始终记录法规版本和评估日期 — 监管指南会不断演进;每份报告都必须标注法规版本和评估日期。
工作流
第 1 步:范围定义
确定哪些法规适用于评估对象:
## Compliance Scope
- Subject: [System / Feature / DPA / Interface being assessed]
- Jurisdictions: [EU / California / Virginia / Colorado / Other states]
- Applicable Regulations:
- [ ] GDPR (EU General Data Protection Regulation)
- [ ] CCPA/CPRA (California Consumer Privacy Act / California Privacy Rights Act)
- [ ] US State Laws (VCDPA, CPA, CTDPA, etc.)
- [ ] ADA / Section 508 (US accessibility)
- [ ] WCAG 2.1/2.2 AA (Web Content Accessibility Guidelines)
- [ ] DPA Review (vendor data processing agreement)
- Personal Data Categories Involved: [list data types]
- Assessment Date: [YYYY-MM-DD]
- Regulation Versions Referenced: [e.g., GDPR as amended 2024, CPRA effective 2023]
第 2 步:GDPR/CCPA 合规检查清单
执行与评估对象相关的检查项:
数据清单与映射
- 已编目所有个人数据类型(姓名、电子邮件、IP、行为数据、生物特征数据等)
- 已记录数据流:收集 → 处理 → 存储 → 共享 → 删除
- 已明确界定每种数据类型的用途,并限制其使用范围
- 已记录处理的法律依据(同意、合法利益、合同、法律义务)
- 已按数据类型定义数据保留期限
同意管理
- GDPR:已针对每种处理目的分别取得同意(而非一揽子接受)
- GDPR:撤回同意与给予同意同样便捷(一键取消订阅)
- CCPA:已提供退出数据出售/共享的机制(“请勿出售或共享我的个人信息”)
- 已保存同意记录(谁同意、何时同意、同意什么)
- 已为跟踪 Cookie 实施 Cookie 同意机制(仅适用于 GDPR)
消费者权利请求处理
- 已建立访问权请求机制(DSR/DSAR 门户或流程)
- 已在规定时限内满足删除权请求(GDPR:30 天,CCPA:45 天)
- 支持数据可携权(GDPR:提供结构化、机器可读的格式)
- 支持更正/修正不准确信息的权利
- DSR 记录至少保存 24 个月(审计跟踪)
第三方与供应商管理
- 已与所有处理个人数据的供应商签订 DPA
- 已维护供应商清单并每年审查
- 国际数据传输已纳入标准合同条款(SCC)
- DPA 中包含对子处理方的通知条款
安全要求
- 已实施合理的安全措施(静态和传输中的加密)
- 已执行访问控制和最小权限原则
- 已记录数据泄露通知流程(GDPR:72 小时内通知监管机构)
- 已对处理活动开展安全风险评估
第 3 步:隐私设计审查
根据 Ann Cavoukian 的 7 项基本原则进行评估:
| 原则 | 评估 |
|---|---|
| 1. 主动而非被动 | 隐私是否从设计阶段就融入其中,而非事后添加? |
| 2. 默认保护隐私 | 默认设置是否为最能保护隐私的设置? |
| 3. 将隐私融入设计 | 隐私是否是系统架构不可或缺的一部分,而非后加的功能? |
| 4. 完整功能 | 隐私是否与正当的业务目标并存? |
| 5. 端到端安全 | 是否确保从收集到删除的整个生命周期安全? |
| 6. 可见性与透明度 | 政策和实践是否公开且可验证? |
| 7. 尊重用户隐私 | 所有设计决策是否都以用户为中心? |
将每项原则记录为:已实施 / 部分实施 / 缺失 / 不适用
第 4 步:ADA/WCAG 无障碍审计
根据 WCAG 2.1 AA(最低标准)/ WCAG 2.2 AA(当前标准)进行评估:
POUR 原则
- 可感知:所有非文本内容都有文本替代;音频/视频配有字幕/文字稿;内容不只依赖颜色区分;普通文本的最低对比度为 4.5:1
- 可操作:所有功能均可通过键盘使用;不存在键盘陷阱;提供跳过导航链接;有充足的交互时间;不存在会引发癫痫的内容(闪烁频率不超过 3Hz)
- 可理解:页面语言已在 HTML 中设置;错误消息描述清晰且有帮助;页面间导航保持一致;表单标签和说明清楚
- 健壮性:HTML/ARIA 有效;兼容当前辅助技术;正确应用 ARIA 标签和角色
AI 界面专属要求(2025+)
- 聊天机器人界面支持键盘操作并兼容屏幕阅读器
- AI 生成的内容具有适当的语义结构
- 为 AI 生成的图像提供替代文本
- 语音界面提供视觉替代方案
无障碍严重程度分类
- 严重:完全阻止残障用户访问(缺少键盘导航、不支持屏幕阅读器)
- 高:显著妨碍使用(对比度差、关键图像缺少替代文本)
- 中:造成使用障碍,但存在变通方法(缺少跳过链接、标签不一致)
- 低:最佳实践方面的改进(装饰性图像使用了非空替代文本)
第 5 步:DPA 验证清单
如果正在审查数据处理协议:
必需的 DPA 要素(GDPR 第 28 条)
- 明确标识各方(控制者名称/地址、处理者名称/地址)
- 明确处理的标的、性质和目的
- 指明个人数据类型和数据主体类别
- 指明处理期限
- 记录控制者的义务和权利
- 处理者的义务:
- 仅根据控制者的书面指示进行处理
- 确保负责处理的人员承担保密义务
- 实施适当的技术和组织安全措施
- 子处理者规则:须事先取得书面同意;将义务传递给子处理者
- 协助控制者处理 DSAR 及履行第 32 至 36 条规定的义务
- 服务结束时删除或返还数据
- 配合审计并提供相关信息
- 指明国际传输机制(SCC、充分性决定等)
- 违规通知流程:处理者须毫不延迟地通知控制者
- DPA 更新触发条件:每年审查,或在处理活动发生重大变化时审查
DPA 质量标记
- 不得使用含糊的处理描述(“按需处理数据”)——必须具体说明
- 详细描述安全措施(加密、访问控制、员工培训)
- 提供并维护子处理者名单
- 针对高风险国家开展传输影响评估(TIA)
步骤 6:监管监测指南
提供有关如何持续保持合规的指南:
监测来源
- GDPR:欧洲数据保护委员会(EDPB)—— https://edpb.europa.eu/
- CCPA/CPRA:加州隐私保护局—— https://cppa.ca.gov/
- 美国州法律:IAPP 州隐私立法追踪器—— https://iapp.org/resources/article/us-state-privacy-legislation-tracker/
- WCAG:W3C WAI—— https://www.w3.org/WAI/
- ADA:美国司法部 ADA.gov—— https://www.ada.gov/
监测频率
- 每月:审查监管机构的执法行动
- 每季度:检查是否有新的或修订的州隐私法律
- 每年:与所有处理者全面审查 DPA;全面进行无障碍审计
- 发生变更时:数据处理活动、供应商或界面发生重大变化时,重新评估
步骤 7:作出合规决定
输出以下三种决定之一:
{
"decision": "PASS | CONDITIONAL | FAIL",
"regulationsAssessed": ["GDPR", "CCPA", "WCAG 2.1 AA", "DPA"],
"assessmentDate": "YYYY-MM-DD",
"findings": [
{
"id": "RC-001",
"regulation": "GDPR",
"severity": "CRITICAL | HIGH | MEDIUM | LOW",
"category": "Consent Management",
"description": "Cookie consent banner missing for analytics tracking cookies",
"status": "FAIL",
"remediation": "Implement cookie consent platform with granular purpose-based opt-in",
"owner": "developer",
"deadline": "Before next deployment"
}
],
"requiredMitigations": [],
"evidencePaths": [".claude/context/reports/compliance/"],
"regulatoryLinks": [
"https://edpb.europa.eu/our-work-tools/documents/public-consultations/2023/guidelines-032023-deceptive-design-patterns_en"
],
"nextReviewDate": "YYYY-MM-DD",
"recommendedNextStep": "Assign RC-001 to developer agent; re-assess after remediation"
}
决定规则:
PASS:所有适用的检查清单项目均已核实,没有未解决的问题CONDITIONAL:存在轻微或中等问题;可在制定书面整改计划后继续FAIL:存在严重或高风险问题;必须在部署前完成整改
输出协议
报告位置
将合规报告保存至:.claude/context/reports/compliance/
命名:{subject}-compliance-{YYYY-MM-DD}.md
报告章节(必需)
- 范围定义(步骤 1 的输出)
- GDPR/CCPA 检查清单结果(步骤 2)
- 隐私保护设计评估(步骤 3)
- 无障碍审计结果(如适用,步骤 4)
- DPA 验证(如适用,步骤 5)
- 结构化决策 JSON(步骤 7)
- 包含负责人和截止日期的整改任务清单
- 监管监测建议
反模式
| 反模式 | 失败原因 | 正确做法 |
|---|---|---|
| 只检查 GDPR,忽略 CCPA 和州法律 | 遗漏多司法管辖区风险 | 始终评估所有适用的司法管辖区 |
| 大多数项目通过时就报告 PASS | 部分合规仍属于不合规 | 存在任何未解决的问题时,标记为 CONDITIONAL/FAIL |
| 补救措施笼统地写成“实施加密” | 开发者无法依据模糊的指导采取行动 | 具体说明:“对 users 表中的 PII 字段采用 AES-256 加密” |
| 将一次性审计视为持续合规 | 法规每季度都会变化 | 建立持续监控的周期 |
| 将无障碍访问视为可有可无 | ADA 诉讼是当前活跃的法律风险 | 公共界面必须符合 WCAG 2.1 AA |
| DPA 中的数据处理说明含糊不清 | 监管机构会拒绝含糊不清的 DPA | 明确指定数据类型、处理目的和保留期限 |
执行钩子
执行前,根据 schemas/input.schema.json 验证输入。
输出契约定义于 schemas/output.schema.json。
执行前钩子:hooks/pre-execute.cjs
执行后钩子:hooks/post-execute.cjs(发出可观测性事件)
记忆协议
开始前:
cat .claude/context/memory/learnings.md
检查以下内容:
- 对类似系统进行的先前合规评估
- 已知的监管模式和记录在案的决策
- issues.md 中尚未解决的合规阻碍
完成后:
- 新的合规发现 → 追加到
.claude/context/memory/issues.md - 监管决策 → 追加到
.claude/context/memory/decisions.md - 成功的合规模式 → 追加到
.claude/context/memory/learnings.md
假设任务可能中断:你的上下文可能会重置。如果没有记录在记忆中,就等于没有发生。
评论
支持 Markdown