AI Segregation of Duties：双控职责分离架构
Segregation of duties prevents efficient automation from becoming concentrated, unchallenged authority.
AI Segregation of Duties / Dual Control Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_SEGREGATION_OF_DUTIES_DUAL_CONTROL_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| FFIEC Management booklet | https://ithandbook.ffiec.gov/it-booklets/management.aspx | 用管理层治理、职责分配、风险管理和控制监督语言定义 AI workflow 的职责边界 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 SoD 风险识别、控制度量和持续改进 |
| ISO/IEC 42001 | https://www.iso.org/standard/42001 | 用 AI management system 语言连接责任、运营控制、绩效评价和管理评审 |
| Federal Reserve SR 26-2 | https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm | 用模型风险治理、验证、独立挑战和证据语言连接 AI 决策控制 |
监管 nuance:
- SR 26-2 于 2026-04-17 发布, 并 superseded SR 11-7 / SR 21-8。
- SR 26-2 附件说明 generative AI 和 agentic AI 不在该 guidance 的直接范围内。
- 但金融零售 GenAI / agentic AI 的 SoD 设计仍应组合 model risk、operational risk、identity / authorization、consumer compliance 和 audit evidence。
- 因此本文不是把 SR 26-2 机械套到 Agent, 而是借用治理、验证、独立挑战和证据思想, 再补上生产 workflow 控制。
核心导读： Segregation of duties prevents efficient automation from becoming concentrated, unchallenged authority.
核心导读
AI automation 会天然压缩职责边界：同一条 agent chain 可能读取客户数据、生成建议、调用工具、写入系统、解释结果并关闭 case。传统 SoD / dual control 的问题在 AI 场景中不是消失了，而是更隐蔽了。架构必须防止“准备、复核、批准、执行、覆盖、审计”由同一人、同一 agent、同一服务账号、同一供应商或同一控制链完成。
成熟设计不是简单多加一个审批按钮，而是把职责冲突、审批前置、动作哈希、权限分离、独立挑战和审计回放嵌入 workflow 和 tool gateway。
问题定义
AI 带来的 SoD 风险主要来自权力集中和责任模糊：
- Agent 起草客户回复，同时决定是否符合政策，并直接发送给客户。
- AI 总结争议证据、建议拒绝、写入 case closure，复核员只点确认。
- Supervisor agent 检查 primary agent，但两者使用同一模型、同一 prompt family 和同一证据来源。
- 同一员工配置 prompt、批准上线、处理 override，并解释审计问题。
- 同一 vendor 提供模型、日志、复核人员和质量报告，缺少独立证据。
- Service account 权限过宽，生产中无法区分 AI、员工和系统动作责任。
SoD 不是降低效率的形式控制，而是阻止自动化将高影响权力集中到无挑战路径中。
核心原理/方法
先建立 duty inventory，而不是从 API permission 开始：
| Duty | 典型动作 | 冲突关注 |
|---|---|---|
| Prepare | 生成草稿、摘要、建议、证据包 | 不能自我批准高影响建议 |
| Validate | 检查事实、政策、适当性、证据完整性 | 不能与 prepare 完全同源 |
| Approve | 接受风险、批准客户影响动作 | 需要授权、独立性和责任 |
| Execute | 写入系统、发送客户消息、触发资金或状态变化 | 必须验证 approval state |
| Override | 覆盖模型、规则、人审或 policy decision | 需要理由、权限和二次复核 |
| Audit | 复盘行为、抽样检查、确认控制有效 | 不能由被审计链路自证 |
Incompatible duty pairs 要明确化。例如：准备退款建议的人或 agent 不能批准退款；配置模型阈值的人不能单独批准阈值例外；供应商 reviewer 不能作为唯一独立挑战来源；同一服务账号不能既提交又批准工具动作。
Dual control 的重点是 approval-before-action。高影响动作应先冻结 action payload，生成 action hash，再由独立角色批准，最后 tool gateway 验证 hash、approval、scope、entitlement 和 expiry 后执行。
系统/架构模型
Identity / Entitlement Store
-> Duty Inventory & Conflict Matrix
-> AI Workflow State Machine
-> SoD Policy Engine
-> Approval & Dual-Control Service
-> Tool / Action Gateway
-> Override Governance
-> Evidence Ledger
-> SoD Monitoring Dashboard
关键组件：
| 组件 | 职责 |
|---|---|
| Identity store | 区分 human、agent、service account、vendor reviewer、supervisor agent 和 system job |
| Conflict matrix | 定义 incompatible duties、同源冲突、团队冲突、供应商冲突和 owner 冲突 |
| Workflow state machine | 明确 draft、submitted、reviewed、approved、executed、overridden、audited 状态 |
| SoD policy engine | 在每次状态转换和工具调用前判断职责冲突和审批要求 |
| Dual-control service | 生成 approval request、action hash、审批链、有效期和撤销机制 |
| Tool gateway | 只执行已批准、未过期、未篡改、权限匹配的动作 |
| Override governance | 记录 override reason、权限、二次复核、客户影响和后续监控 |
| Evidence ledger | 保存 actor chain、decision chain、action hash、policy decision 和审计 replay |
架构目标不是让所有动作都双人审批，而是让高影响动作不能由同一责任链自我批准。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| 自动化效率 vs 独立挑战 | AI 可以压缩准备时间，但不应消除高影响动作的独立挑战 |
| Supervisor agent vs 人类 checker | Supervisor agent 可做辅助检查，但如果同源、同模型、同权限，就不是独立控制 |
| 阈值分层 vs 全量审批 | 小额低风险动作可自动化；客户资金、拒绝争议、投诉关闭、适当性建议等需要强控制 |
| 权限分离 vs 工作流分离 | API 权限只是基础；真正的 SoD 要按业务 duty 和 workflow state 分离 |
| 团队独立 vs 供应商独立 | 外包复核不自动等于独立，需看激励、证据、权限和质量控制 |
| 例外审批 vs 控制绕过 | 紧急 override 需要二次复核、到期和事后抽样，不能成为隐藏后门 |
SoD 设计要同时考虑人、agent、服务账号和供应商。AI 系统中“actor”不再只是员工 id，而是一条由模型、prompt、工具、队列、审批人和服务账号组成的 actor chain。
证据与控制
可审计 SoD 证据要证明职责没有冲突，或冲突被批准并补偿：
| 证据对象 | 关键字段 |
|---|---|
| Duty assignment | actor id、actor type、role、team、vendor、entitlement、effective date |
| Conflict decision | duty pair、conflict rule、decision、policy version、reason |
| Approval event | approver、authority、action hash、scope、expiry、evidence reviewed |
| Tool execution | tool name、payload hash、approval id、executor、result、idempotency key |
| Override record | overridden control、reason code、owner、second review、customer impact |
| Audit replay | prepare-review-approve-execute chain、timestamps、versions、logs |
| Monitoring metric | SoD violation、same-actor approval、override concentration、checker workload |
控制指标应覆盖：unapproved high-impact action、same-chain approval、expired approval execution、service-account concentration、vendor-only review、override aging、checker overload、post-approval payload mismatch。
金融零售/AI产品场景
争议拒绝与退款：AI 可准备证据摘要和建议，但拒绝客户争议、发起退款或关闭 case 需要独立审批。Tool gateway 必须验证 action hash 与审批时 payload 一致。
信用额度调整：模型建议额度变化，AI 生成解释。高影响客户动作应区分分析、建议、审批、执行和客户沟通，不允许同一 agent chain 直接完成全流程。
AML case closure：AI 可汇总交易和生成 narrative。关闭 case、降低风险评级或决定不报送应有独立复核，并保留 reviewer 看到的原始证据。
营销活动发布：AI 生成 campaign copy 和客户分群。生成、合规审查、目标人群批准、上线发布和效果复盘应分离，尤其要防止销售 KPI owner 独自批准高风险话术。
反模式
- 把第二次 LLM 调用当作 checker，却没有独立模型、证据、规则或责任。
- 只做 RBAC，不定义 prepare、approve、execute、override 等业务 duty。
- 同一服务账号代表所有 AI 动作，无法区分责任链。
- 高影响工具调用先执行后审批。
- 复核员无法看到原始证据，只能看 AI 摘要。
- override 没有 reason taxonomy、二次复核和集中度监控。
- 审计只能看到最终自然语言解释，无法回放 actor chain 和 action hash。
最终心智模型
AI SoD / dual control 的核心是防止自动化把“能做、该做、可批准、已执行、可审计”压缩成同一条无挑战链路。AI 可以准备材料、加速检查、减少人工劳动，但不能把高影响授权集中到不可解释的 agent 路径中。
成熟架构能证明：每个客户影响动作由谁准备、谁复核、谁批准、谁执行、谁覆盖、谁审计；任何职责冲突都被 policy engine 识别、由有权角色接受，并在 evidence ledger 中可复盘。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。