AI Segregation of Duties / Dual Control / Maker-Checker Architecture Playbook

定位: 面向高级 AI PM / AI BA / AI Product Architect / Enterprise Architect / Risk Technology Lead / Operations Lead / Internal Audit Partner, 把 AI segregation of duties 从“权限配置”升级为可设计、可运营、可度量、可审计的生产控制体系。 适用范围: agentic workflow、AI copilot、AML assistant、payment dispute assistant、credit underwriting copilot、complaint remediation agent、KYC review assistant、customer service RAG、vendor AI reviewer、AI platform tool gateway。 重要说明: 本文是学习、作品集和内部治理训练材料, 不是法律意见、合规结论、审计意见、模型验证报告或监管解释。正式项目必须由 Legal、Compliance、Risk、Model Risk、Internal Audit、Security、Privacy、Business Owner、Operations Owner、IAM Owner 和管理层结合机构类型、司法辖区、业务用途、客户影响和内部政策确认。

---

1. Executive Framing

Segregation of duties, dual control 和 maker-checker 不是旧时代后台操作流程。 在 AI workflow 中, 它们反而更重要。 原因很简单: AI agent 可以同时读数据、解释证据、推荐动作、调用工具、起草客户沟通、生成审计摘要。 如果设计不当, 一个“高效 agent”会把过去分散在 analyst、reviewer、supervisor、operator、auditor 和 system admin 之间的职责合并成单点权力。 本 playbook 的核心判断:

AI risk is not only unauthorized access.
It is incompatible duties collapsing into one automated chain.

中文表达:

AI 风险不只是越权访问, 也是不相容职责被自动化压缩成一条链。

1.1 与 Generic Authorization 的区别

1.2 为什么 AI 让 SoD 更难

• AI maker 的输出可能看起来非常完整, 让 checker 放松独立判断。
• Copilot 可能预填审批理由, 降低人类 challenge 质量。
• Supervisor agent 可能与 worker agent 使用同一模型、同一知识源和同一 owner。
• Tool gateway 只校验 scope, 不校验 maker 是否等于 approver。
• 运营 KPI 可能奖励速度, 使 reviewer 变成形式按钮。
• Vendor 可能提供模型、监控和 incident report, 但缺少独立接受验证。
• Audit trail 可能只保存最终摘要, 缺少原始证据、审批链和参数 hash。

1.3 成熟 SoD 的目标

成熟设计要能回答:

---

2. Source Anchors

以下官方来源作为治理和控制设计锚点。本文把它们转成 AI workflow role boundary、maker-checker、dual authorization、independent challenge、entitlement separation 和 audit evidence 的设计语言。

2.1 SR 26-2 Nuance

SR 26-2 于 2026-06-24 发布, superseded SR 11-7 和 SR 21-8。 它的附件说明 generative AI 和 agentic AI 不在该 guidance 的直接范围内。 这意味着不能把 SR 26-2 简单当作 GenAI / agentic AI 的完整操作手册。 但金融零售 AI SoD 仍需要吸收其中的模型风险治理思想:

• 明确模型和系统用途。
• 区分开发、使用、验证和监督职责。
• 保留可复核证据。
• 对关键控制做独立挑战。
• 在变更、问题和重大使用场景中重新评估风险。 对于 GenAI / agentic AI, SoD 还必须额外组合:
• operational risk: 流程中断、错误执行、队列拥堵、人工复核失效。
• identity / authorization: agent identity、delegated scope、tool gateway、approval token。
• consumer compliance: 客户可见沟通、投诉、信贷、支付、隐私、公平性和弱势客户。
• audit evidence: maker、checker、approver、executor、override、policy version、action hash、result。

2.2 Mapping To NIST AI RMF

---

3. SoD Taxonomy For AI Workflows

3.1 Duty Families

3.2 Actor Types

3.3 SoD Control Strength Levels

3.4 AI-Specific Independence Dimensions

独立性不能只看是否不同姓名。

---

4. Incompatible Duty Matrix

4.1 Core Matrix

4.2 Financial Retail Matrix

4.3 AI Platform Matrix

4.4 Conflict-Of-Interest Signals

---

5. Dual-Control Patterns

5.1 Pattern A: Classic Maker-Checker

Use when one role prepares and another role verifies before workflow advances.

AI or human maker
  -> evidence packet
  -> independent checker workbench
  -> accept / edit / reject / escalate
  -> evidence ledger

适合:

• 客户可见回复草稿。
• 信贷 memo 草稿。
• AML narrative 草稿。
• KYC evidence summary。 设计要求:
• checker 看到原始 evidence, 不是只看 AI summary。
• checker action 不是默认 approve。
• checker reason code 进入日志。
• maker 不能修改 checker decision。

5.2 Pattern B: Four-Eyes Approval

Use when one human approval is insufficient but full committee is too slow.

maker proposal
  -> first approver
  -> second approver with independent authority
  -> single-use approval token
  -> tool execution

适合:

• 高额 provisional credit。
• 账户冻结或解除。
• 高影响投诉赔付。
• 高风险 KYC status 变更。 设计要求:
• second approver 不属于同一冲突链。
• 两个批准绑定同一 action hash。
• 任一批准过期则重新审批。
• disagreement 进入 adjudication。

5.3 Pattern C: Dual Authorization For Tools

Use when tool action has direct side effect.

AI proposes tool call
  -> policy engine marks dual_control_required
  -> approver A validates business reason
  -> approver B validates risk / compliance boundary
  -> tool gateway verifies both approval IDs
  -> execute exact request hash

适合:

• funds movement。
• adverse customer notice。
• SAR-related submission package。
• customer data export。

5.4 Pattern D: Independent Challenge

Use when the issue is judgment, not only approval.

AI recommendation
  -> checker reviews evidence without relying on AI conclusion
  -> challenge questions answered
  -> approve, reject, modify or escalate

Challenge questions:

• 哪些证据支持结论。
• 哪些证据冲突。
• 哪条 policy 或 rule 适用。
• 是否存在 customer harm。
• 是否存在 missing evidence。
• 是否存在 conflict of interest。

5.5 Pattern E: Post-Action Independent QA

Use when bounded automation is allowed but still needs assurance.

bounded auto action
  -> sampling strategy
  -> independent QA
  -> defect classification
  -> control tuning
  -> management report

适合:

• 低风险自动分类。
• 标准内部 case note。
• 低影响 routing。
• RAG answer sample QA。

5.6 Pattern F: Break-Glass Dual Control

Use when emergency access or override could cause large harm.

incident request
  -> incident commander approval
  -> security / risk approval
  -> time-boxed emergency entitlement
  -> enhanced logging
  -> post-incident review

原则:

• AI agent 默认不能自主触发 break-glass。
• break-glass 不能成为长期 admin 后门。
• 恢复普通权限前必须做证据复盘。

---

6. Workflow Controls

6.1 State Machine

生产 workflow 应显式建模职责状态。

draft_created
  -> maker_submitted
  -> checker_assigned
  -> checker_decided
  -> approval_pending
  -> dual_approval_complete
  -> execution_ready
  -> executed
  -> qa_sampled
  -> closed

禁止状态跳跃:

6.2 Policy Inputs

SoD policy engine 至少使用:

• actor id。
• actor role。
• actor team。
• agent id and version。
• workflow run id。
• case owner。
• prior maker id。
• prior checker id。
• requested action。
• risk tier。
• amount。
• customer impact。
• regulatory sensitivity。
• approval state。
• entitlement scope。
• conflict flags。

6.3 Policy Outputs

6.4 Approval Binding

Approval must bind exact action, not just intent.

6.5 Evidence-First Checker UI

Recommended order:

Case context
-> Proposed duty and action
-> Customer / financial / regulatory impact
-> Original evidence and citations
-> AI recommendation and uncertainty
-> Policy / SoD decision
-> Conflict flags
-> Available actions
-> Required reason code

Anti-patterns:

• approve button appears before evidence。
• AI confidence is shown without source support。
• checker cannot see who made the recommendation。
• checker cannot reject or escalate。
• free-text reason is the only evidence。
• UI hides downstream tool impact。

6.6 Override Controls

Override is not failure by default. It is a controlled business action.

6.7 Rubber-Stamp Detection

Rubber-stamp review is a SoD failure. Signals:

• checker approval time is consistently below realistic evidence review time。
• override rate collapses after productivity target changes。
• reason code is always generic。
• same checker approves same maker repeatedly。
• second approval occurs within seconds for complex cases。
• QA finds missed evidence while checker logs show complete review。 Controls:
• minimum evidence panel interaction for high-risk cases。
• blind review for calibration cases。
• gold case injection。
• reviewer quality dashboard。
• supervisor coaching and certification removal。

---

7. Entitlement Model

7.1 Duty-Based Entitlements

Do not grant broad workflow permissions. Use duty-specific scopes.

7.2 Separation Rules

7.3 Agent Identity Requirements

每个 agent 必须有:

• agent_id。
• agent_version。
• business owner。
• technical owner。
• risk owner。
• allowed duty roles。
• prohibited duty roles。
• tool allowlist。
• max autonomy level。
• checker requirements。
• evidence logging profile。 Example: | Field | Value | |---|---| | Agent | Payment Dispute Assistant | | agent_id | payment-dispute-agent-prod | | Allowed duty | retrieve, extract, summarize, draft, recommend | | Prohibited duty | final approve, funds execute, complaint close, audit certify | | Checker requirement | payment specialist for customer-impacting action | | Dual control | amount above threshold or fraud / complaint flag | | Evidence profile | enhanced trace for all recommendations |

7.4 Service Account Boundary

Service accounts execute technical calls but do not own business approval. Tool logs must include:

• service principal。
• human initiator。
• agent id。
• workflow run。
• maker id。
• checker id。
• approval id。
• action hash。
• policy decision。
• execution result。

7.5 Access Review

Monthly or event-driven review should cover:

• stale checker roles。
• agents with prohibited duty scopes。
• service accounts with execute permission but no approval-bound constraint。
• repeated emergency overrides。
• tool scopes unused for 90 days。
• vendors with broad evidence access。
• audit users with write access to evidence store。

---

8. Maker-Checker Templates

8.1 Maker-Checker Requirement Pattern

For payment dispute provisional credit above the frontline threshold,
when AI or a frontline analyst recommends a credit,
the system must route the recommendation and evidence packet to a certified payment dispute checker
who is not the maker, not the case creator, and not in a conflicted incentive role,
before any payment tool can execute,
capturing maker id, checker id, evidence viewed, decision, reason code, approval id, action hash and timestamp.

8.2 Filled Design Brief

8.3 Checker Workbench Acceptance Criteria

• Checker can see maker identity and AI version。
• Checker can see original sources and policy effective date。
• Checker can see customer and financial impact。
• Checker can reject without manager workaround。
• Checker can request evidence without approving。
• Checker can escalate to specialist queue。
• Checker decision requires structured reason for high-risk cases。
• Tool execution is blocked until checker state is complete。

8.4 Dual Authorization Card

8.5 Independent Challenge Checklist

• Reviewer identified at least one supporting evidence item。
• Reviewer identified conflicting or missing evidence。
• Reviewer confirmed source version and effective date。
• Reviewer checked whether AI used prohibited factor or stale source。
• Reviewer confirmed customer impact and reversibility。
• Reviewer confirmed no role conflict or self-approval。
• Reviewer selected reason code tied to evidence。
• Reviewer documented escalation or override rationale。

8.6 Audit Evidence Schema

---

9. Dashboards And KRIs

9.1 SoD Control Dashboard

9.2 Quality And Independence Dashboard

9.3 Risk KRIs

9.4 Executive View

Executives should see:

• high-risk actions attempted。
• high-risk actions executed。
• percentage with complete maker-checker evidence。
• dual-control exception count。
• material overrides and owners。
• control breaches and customer impact。
• reviewer capacity and SLA。
• audit replay success。
• open CAPA from SoD failures。

---

10. RACI

10.1 Three Lines View

10.2 Governance Cadence

| Review | Frequency | Output | |---|---| | Operations review | weekly | queue SLA, violation attempts, evidence gaps | | Risk/control review | monthly | KRI trend, override concentration, exception acceptance | | Access recertification | monthly or on change | duty scopes, stale roles, service account constraints | | Model/control challenge | per release and periodic | independence assessment, eval and validation evidence | | Audit replay | quarterly or risk-based | replay results, findings, CAPA | | Management review | quarterly | residual risk, investment, control maturity |

---

11. Financial Retail Examples

11.1 Payments: Card Dispute Provisional Credit

Business goal: Speed up dispute handling while preventing unauthorized credits, wrong denials and weak customer evidence. Duty design:

• provisional credit wrong amount。
• action executed without dual approval。
• same-maker-checker block。
• complaint escalation after denial。
• evidence missing transaction or rule deadline。

11.2 AML: Alert Triage And Case Closure

Business goal: Improve investigation quality without letting AI close suspicious activity prematurely. Duty design:

• AI cannot be sole basis for alert closure。
• High-risk typology requires senior review。
• SAR-sensitive content uses restricted evidence handling。
• QA samples include cases where AI recommended no escalation。

11.3 Lending: Credit Underwriting Copilot

Business goal: Improve memo quality and policy citation without collapsing underwriting, approval and fair lending review. Duty design:

• Sales cannot approve its own exception。
• AI cannot generate unsupported adverse action reasons。
• Protected-class and proxy-factor checks require evidence。
• Human decision owner sees AI limitations and source versions。

11.4 Complaint Remediation Agent

Business goal: Draft consistent remediation responses and route complaints without auto-closing regulated complaints. Duty design:

• Legal threat, regulator mention, vulnerability and discrimination signals force escalation。
• Customer remediation amount uses dual approval above threshold。
• Closure requires evidence checklist and reviewer signoff。
• AI-generated root cause does not replace management accountability。

---

12. 30-Day Lab

目标: 30 天内完成一套可展示的 AI Segregation of Duties / Dual Control architecture portfolio pack。 推荐选择 Payment Dispute Assistant、AML Copilot、Credit Underwriting Copilot 或 Complaint Remediation Agent。

Week 1: Discovery And Duty Inventory

Week 2: Control Design

Week 3: Evidence, Monitoring And Operations

Week 4: Case Study And Interview Pack

Completion Standard

---

13. Interview Answers

Q1: What is the difference between authorization and segregation of duties in AI?

30 秒:

Authorization asks whether an actor can perform an action. Segregation of duties asks whether the same actor should be allowed to prepare, recommend, approve, execute, override and audit the same outcome. In AI workflows, this matters because an agent can collapse many roles into one automated chain. 2 分钟: I would start with a duty inventory rather than a permission list. For example, a payment dispute assistant may retrieve evidence, summarize the case, recommend provisional credit, draft a customer message and request a payment tool call. Generic authorization might say the agent has a payment scope. SoD asks which of those duties are incompatible. The agent can be maker for evidence and recommendation, but a certified payment specialist must check the recommendation, a supervisor may need second approval above threshold, and the tool gateway must execute only an approval-bound action hash. The evidence ledger records maker, checker, approver, executor, policy version and result.

Q2: How would you design maker-checker for an AI copilot?

30 秒:

I separate the AI maker role from the checker role. The AI can produce a recommendation and evidence packet. The checker must see original evidence, policy version, customer impact and AI uncertainty, then approve, edit, reject or escalate with a reason code. 2 分钟: I would define the review unit first: claim, recommendation, draft, tool action or case closure. Then I would route it based on risk tier, customer impact and conflict rules. The checker cannot be the maker, cannot be in a conflicted role and must have authority to challenge. The UI is evidence-first, not approve-first. For side-effect actions, approval is bound to an action hash and the tool gateway blocks execution unless the approval state, scope and workflow state match.

Q3: Can a supervisor agent act as checker?

30 秒:

It can support low-risk consistency checks, but for high-impact financial, compliance or customer-facing actions I would not treat another LLM call as independent control by itself. 2 分钟: A supervisor agent may catch formatting errors, missing fields, policy conflicts or tool schema violations. But independence depends on role, model, data, owner and authority. If the supervisor agent uses the same model, same prompt family, same evidence summary and same team owner, it is weak independence. For AML, lending, payments and complaints, I would combine supervisor agent checks with external policy gates, human specialist review, dual authorization and audit sampling.

Q4: What are common incompatible duties in AI workflows?

The common ones are: recommendation and approval, evidence extraction and evidence sufficiency certification, draft and final customer send, refund proposal and funds release, AML risk summary and alert closure, credit memo draft and final credit decision, model build and model validation, control operation and control testing, vendor incident reporting and internal acceptance.

Q5: How do you prevent rubber-stamp human review?

I would monitor review time, override rate, reason quality, gold case accuracy, maker-checker pair concentration and QA defect rate. The checker workspace must show original evidence, missing evidence, policy version, customer impact and conflict flags. For high-risk cases I may use blind review, delayed reveal, double review and calibration. A near-zero override rate is not automatically good; it may indicate automation bias.

Q6: What evidence proves SoD worked?

Evidence should include duty chain, not just output. I need maker id, checker id, approver ids, agent version, workflow run, source ids, policy version, SoD decision, approval id, action hash, tool execution result, override reason and audit sample flag. Audit should be able to replay the case and confirm that the actor who made the recommendation did not approve or execute it improperly.

Q7: How does SoD apply to model risk management?

Model teams can build, tune and operate models, but independent validation or challenge should test model use, assumptions, limitations, monitoring and control effectiveness. For GenAI and agentic AI, that independence must be combined with operational controls: tool gateways, approval workflows, identity claims, evidence logging and consumer compliance checks. SR 26-2 superseded SR 11-7 and SR 21-8, but GenAI and agentic AI need additional workflow and authorization controls beyond model risk alone.

Q8: How would you explain dual control to a product executive?

Dual control is intentional friction for high-impact actions. It protects the business from one person, one agent or one workflow chain making and executing a consequential decision alone. We still use AI to prepare evidence and reduce handling time, but funds movement, account restriction, adverse customer action and regulatory-sensitive closure require independent approval and evidence. The goal is controlled automation, not unmanaged speed.

Q9: What is the architecture pattern?

The pattern is workflow orchestrator plus SoD policy decision point plus checker workbench plus approval service plus tool gateway plus evidence ledger. The orchestrator tracks duty state. The policy engine decides whether a checker, dual approval or specialist is required. The approval service binds decision to action hash. The tool gateway enforces approval-bound execution. The evidence ledger keeps the duty chain for audit replay.

Q10: What would you put in acceptance criteria?

I would require that no high-risk action executes without complete duty chain evidence, no maker can approve own work, no dual-control action can use the same approver twice, no approval can execute with changed parameters, and audit can replay the maker-checker-approver-executor chain. I would also require dashboards for SoD violations, rubber-stamp review, override concentration, action hash mismatch and evidence completeness.

---

14. Common Pitfalls

---

15. Final Operating Principle

AI SoD is not bureaucracy for its own sake. It is the control system that lets an organization safely use AI speed without concentrating incompatible authority. For高级 AI PM / BA / Architect, the practical skill is to turn this principle into workflow states, duty-specific entitlements, maker-checker queues, dual-control gates, action-bound approvals, KRI dashboards and replayable audit evidence.