61 lines
4.9 KiB
Markdown
61 lines
4.9 KiB
Markdown
---
|
||
title: "Compliance Auditor Agent"
|
||
type: source
|
||
tags: []
|
||
date: 2026-04-25
|
||
---
|
||
|
||
## Source File
|
||
- [[Agent/agency-agents/specialized/compliance-auditor.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：专业 AI Agent，专注于 SOC 2、ISO 27001、HIPAA、PCI-DSS 等安全隐私认证审计的全流程指导——从准备评估到证据收集直至认证通过。
|
||
- 问题域：组织如何系统性地通过合规认证，避免"打勾式合规"（checkbox compliance），确保控制措施真正落地而非仅存在于文档中。
|
||
- 方法/机制：五步工作流（Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance）；强调自动化证据收集、右置控制项设计、以审计员视角反向思考。
|
||
- 结论/价值：合规项目应与公司规模和实际风险匹配；技术控制优于管理控制；证据必须证明控制在整个审计周期内持续有效，而非仅存在于当下。
|
||
|
||
## Key Claims（用中文描述）
|
||
- 不被遵守的政策比没有政策更危险——它制造虚假信心，增加审计风险。
|
||
- 自动化证据收集从第一天就应建立——手动流程无法扩展。
|
||
- 使用通用控制框架（common control framework）可一个控制集满足多个认证标准。
|
||
- 技术控制优于管理控制——代码比培训更可靠。
|
||
- 审计边界（scope）必须清晰定义，明确包含和排除的范围。
|
||
- 例外情况（exceptions）需要完整文档：谁批准、为什么、有何时效、有何补偿控制。
|
||
|
||
## Key Quotes
|
||
> "A policy nobody follows is worse than no policy — it creates false confidence and audit risk."
|
||
> — 核心原则：不follow的政策比没政策更危险
|
||
|
||
> "Evidence must prove the control operated effectively over the audit period, not just that it exists today."
|
||
> — 证据的核心要求：证明整个审计周期内持续有效
|
||
|
||
> "Think like the auditor: what would you test? what evidence would you request?"
|
||
> — 审计员心态：反向思考，模拟审计师会问什么
|
||
|
||
## Key Concepts
|
||
- [[Checkbox-Compliance]]：仅在文档层面满足合规要求，控制实际未落地或未被测试——文档中的反面案例。
|
||
- [[Continuous-Compliance]]：持续合规——在两次年度审计之间建立自动化证据收集管道和季度控制测试机制，而非年度突击准备。
|
||
- [[Common-Control-Framework]]：通用控制框架——设计一组控制项同时满足多个认证标准（如 SOC 2 + ISO 27001），避免重复工作。
|
||
- [[Technical-Controls-Vs-Administrative-Controls]]：技术控制（如 IAM 策略、代码审计）优于管理控制（如培训、签到表），因为代码比人的行为更可靠。
|
||
- [[Compensating-Control]]：补偿控制——当某项控制无法直接满足时，用于降低风险的替代措施；需完整记录批准人、原因和有效期。
|
||
- [[Evidence-Collection-Matrix]]：证据收集矩阵——以控制目标（而非内部团队结构）组织证据的结构化文档，列出控制ID、证据类型、来源、收集方式和频率。
|
||
|
||
## Key Entities
|
||
- [[SOC-2]]：安全、可用性、处理完整性、机密性、隐私五大信任服务标准（Trust Service Criteria），最常见的云服务安全认证。
|
||
- [[ISO-27001]]：国际信息安全管理标准，提供系统化的风险管理方法。
|
||
- [[HIPAA]]：美国医疗信息隐私法规，涵盖 PHI（受保护健康信息）的保护要求。
|
||
- [[PCI-DSS]]：支付卡行业数据安全标准，适用于处理信用卡信息的组织。
|
||
|
||
## Connections
|
||
- [[specialized-model-qa]] ← extends ← [[compliance-auditor]]：Model QA 关注 ML 模型质量，Compliance Auditor 关注整体安全控制——两者在模型部署合规证据收集上存在交叉。
|
||
- [[automation-governance-architect]] ← depends_on ← [[compliance-auditor]]：合规审计所需的自动化证据收集需依托 Governance Architect 设计的 AI 系统治理框架。
|
||
- [[CTP-Topic-52-3-Lines-of-Defence]] ← extends ← [[compliance-auditor]]：三道防线模型（业务管理 / 风险职能 / 内部审计）与合规审计的职责划分高度对应。
|
||
- [[DevSecOps]] ← extends ← [[compliance-auditor]]：DevSecOps 将安全控制集成到 CI/CD 流水线中，是合规 Auditor 推荐的技术控制实现方式。
|
||
|
||
## Contradictions
|
||
- 与 [[specialized-model-qa]] 的侧重点差异：
|
||
- 冲突点：Compliance Auditor 关注组织级控制（access control, incident response），Model QA 关注模型本身的质量与统计特性，两者对"证据"的定义不同。
|
||
- 当前观点：合规证据以控制操作日志、策略文档、访问审查记录为主。
|
||
- 对方观点：模型证据以 PSI、校准曲线、SHAP 值等统计指标为主。
|
||
- 协调建议：两者可互补——Compliance Auditor 负责整体安全框架，Model QA 负责嵌入其中的 AI/ML 模型专项审计。
|