AI Segregation of Duties / Dual Control Architecture 解读

面向对象: AI Product Architect / AI PM / Senior BA / Solutions Architect / Risk Technology Lead / Internal Audit Partner。 核心问题: AI agent、copilot、analyst、reviewer 和 supervisor 不能因为效率而合并不相容职责。SoD 的重点不是“谁有权限”, 而是“哪些职责不能由同一主体完成”。 学习目标: 建立 maker-checker、four-eyes、dual authorization、independent challenge、conflict-of-interest、entitlement separation、approval-before-action、override ownership 和 audit evidence 的完整控制设计语言。

---

Source Anchors

监管 nuance:

• SR 26-2 于 2026-06-24 发布, 并 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.

---

1. Thesis

AI SoD 不是 generic authorization。

Generic authorization 问:

Can this user or agent perform this action?

Segregation of duties 问:

Should the same user, agent, team, model, reviewer or supervisor be allowed
to prepare, recommend, approve, execute, override and audit the same outcome?

这一区别在 agentic AI 中特别重要, 因为一个 workflow 可能把多个传统角色压缩进同一条自动化链:

AI extracts facts
  -> AI recommends decision
  -> AI drafts customer message
  -> AI requests tool execution
  -> AI self-checks
  -> supervisor agent approves
  -> workflow executes

如果这些步骤没有职责隔离, 系统会形成“自我制造、自我批准、自我证明”的闭环。

---

2. Why It Matters

金融零售 AI 的伤害往往不是单个回答错误, 而是控制链被压扁:

AI 产品追求 frictionless workflow, 但 SoD 的目标是 intentional friction。

好的摩擦会保护客户、机构和员工:

• 防止未经独立复核的客户影响动作。
• 防止 agent 自己扩大权限或绕过审批。
• 防止人类 reviewer 成为形式按钮。
• 防止 override 没有 owner、理由和证据。
• 防止审计只能看到一段漂亮自然语言总结。

---

3. Core Concepts

---

4. Reference Architecture

User / Event
  -> Workflow Orchestrator
  -> AI Maker Role: extract, summarize, draft, recommend
  -> SoD Policy Decision Point
  -> Checker Workbench or Control Service
  -> Dual Authorization Gate for high-impact actions
  -> Tool Gateway / Policy Enforcement Point
  -> System of Record
  -> Evidence Ledger
  -> Independent QA / Audit Replay

关键架构原则:

• Maker 和 checker 是 workflow role, 不一定都是人。
• Checker 不能只是同一个 prompt 的第二次调用。
• Supervisor agent 可以辅助检查, 但不能替代高影响动作的人类或独立控制责任。
• Tool gateway 必须验证 approval state、SoD rule、actor chain、entitlement 和 action hash。
• Evidence ledger 要能证明谁准备、谁复核、谁批准、谁执行、谁覆盖、谁审计。

---

5. Financial Retail Case: Payment Dispute Agent

场景:

客户提交信用卡争议。AI assistant 读取交易、商户、客户陈述、规则摘要和历史 case, 推荐是否发放临时贷记并草拟客户通知。

职责拆分:

设计判断:

• 低金额、低风险、证据充分的内部分类可自动化。
• 客户资金动作、拒绝争议、投诉升级、欺诈信号和监管 deadline 不应由同一 AI chain 自我批准。
• Agent 可以缩短准备时间, 但不能消除 independent challenge。

---

6. PM / BA / Architect Checklist

• 是否列出了完整 duty inventory, 而不是只列 API permission。
• 是否标出 maker、checker、approver、executor、override owner、auditor。
• 是否定义 incompatible duty pairs。
• 是否区分 human、agent、supervisor agent、service account、vendor reviewer。
• 是否把 SoD rule 放进 policy engine 或 workflow gate, 而不是只写在培训材料。
• 是否把 read、draft、submit、approve、execute、override、audit scope 分开。
• 是否对高影响动作使用 approval-before-action 和 action hash。
• 是否检测同一用户、同一 agent、同一团队、同一模型 owner、同一 vendor 的冲突。
• 是否定义 override authority、reason taxonomy 和 second review。
• 是否有 dashboard 监控 SoD violation、checker workload、override concentration 和 audit replay。

---

7. Code-Lite Experiment

目标: 用一个小规则引擎模拟 SoD gate。

def sod_decision(actor, action, case):
    if action["type"] == "approve" and actor["id"] == case["maker_id"]:
        return "deny: maker cannot approve own work"
    if action["type"] == "execute" and not case.get("approval_id"):
        return "deny: execution requires approval"
    if action["type"] == "override" and actor["role"] not in case["override_roles"]:
        return "deny: actor lacks override authority"
    if action["type"] == "approve" and actor["team"] == case["sales_team"] and case["domain"] == "credit_exception":
        return "escalate: conflict of interest"
    return "allow"

---

8. Interview Questions

Q1: SoD 和普通授权有什么区别?

30 秒:

普通授权问“这个主体能不能做某个动作”。SoD 问“这个主体是否应该同时承担准备、建议、批准、执行、覆盖和审计这些不相容职责”。AI 场景里, 最大风险是 agentic workflow 把 maker、checker、executor 和 auditor 压缩成一条自动化链。

Q2: 如何设计 AI maker-checker?

我会先做 duty inventory, 把 extract、recommend、draft、approve、execute、override、audit 拆开。AI 可以作为 maker 生成证据包和建议, checker 必须能看到原始证据、policy result、客户影响和不确定性。高影响动作进入 dual authorization, 执行工具只接受绑定 approval id 和 action hash 的请求。

Q3: Supervisor agent 能不能作为 checker?

可以作为低风险一致性检查、格式检查或策略预筛, 但不能默认替代独立人类或独立控制职能。对于资金、账户、信贷、AML、投诉和客户可见负面结论, supervisor agent 应被视为控制层的一部分, 但仍要有 SoD policy、人工权限、证据和审计。

Q4: 如何证明 SoD 控制有效?

要有 evidence ledger, 能重建 maker、checker、approver、executor、override owner、policy decision、approval packet、tool result 和 audit sample。Dashboard 要看 SoD violation attempts、same-actor block、override concentration、rubber-stamp approval、checker SLA、dual-control exception 和 audit replay success。

---

9. Common Pitfalls