AI 底层逻辑 / 经典论文

AI Three Lines Governance：决策权与保证运营模型架构

417 行ai-foundations/papers/174-ai-three-lines-governance-decision-rights-assurance-operating-model-architecture.md

AI 三道防线治理架构：Three Lines Governance / Decision Rights / Assurance Operating Model

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_THREE_LINES_GOVERNANCE_DECISION_RIGHTS_ASSURANCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Date: 2026-06-30 Status: evergreen Audience: experienced CBAP / 金融零售 AI 产品与架构从业者 / AI governance lead / risk-audit partner

重要边界:

本文不是法律意见、监管解释、审计意见、模型验证结论、内控有效性结论或生产上线批准。
本文不重复 product responsibility、stakeholder coalition、model validation、continuous control monitoring、board reporting 和 segregation of duties 的完整框架。
本文只解决一个高级问题: 金融零售企业如何把 AI 治理从"委员会审批"升级为按三道防线分工运行的 enterprise operating model。

核心导读

AI Three Lines Governance 是把 AI 产品、业务运营、风险合规、内部审计和架构治理连接成一套可决策、可挑战、可取证、可整改、可追踪的 operating model。它不是多开几个委员会，也不是让风险、合规或审计替第一线承担上线责任；核心是把“谁拥有业务决策和残余风险”“谁解释政策、挑战证据和提出条件”“谁独立验证治理与控制是否如声明运行”拆清楚。AI 系统里的 prompt、model、RAG source、tool permission、agent action、human workflow、vendor dependency 和客户沟通会持续变化，所以责任边界必须跟生命周期一起运行，而不是停在一次性 sign-off。

金融零售 AI 的系统价值，来自把 use case intake、risk tiering、control ownership、evidence forum、gate decision、issue register、management action、ADR/ARB 和 audit universe 连接成同一条运行链。这样一来，contact center RAG、AML copilot、KYC onboarding、credit decision support 或 enterprise knowledge assistant 都不会只留下“风险已审批”的会议纪要，而是留下可复核的 owner、control objective、evidence object、challenge position、open issue disposition 和 review trigger。

评估证据关注的是治理是否真的工作：gate decision 是否绑定模型、prompt、数据、来源、工具权限、人工流程、eval 和 policy 版本；second-line challenge 是否有条件、异议、升级和关闭证据；management action 是否有 owner、到期日、验收标准和 reopen trigger；third line 是否能抽样验证声明的控制运行，而不是被拉进 release approval。没有这些证据，AI 治理会退化成文档堆、截图包和事后补材料。

控制边界必须硬化：第一线不能把上线与运营责任外包给风险合规，第二线不能变成交付 owner，第三线不能批准自己未来要审计的系统。未关闭的高风险 challenge、长期 aging issue、重复发现、重大模型/提示词/RAG/工具/供应商变更，都应重新打开 gate 或触发范围收缩、暂停、rollback、正式例外或风险接受。真正要防的是客户被错误拒绝、被错误建议、被错误解释、被过度自动化处理，或监管场景中机构无法证明谁决定了什么、基于什么证据、如何整改。

问题定义

AI 产品常见治理失败不是因为没有流程, 而是因为 decision rights 和 evidence ownership 模糊:

产品团队认为风险已签字
风险团队认为只是提出意见
合规团队认为业务仍需自担责任
审计团队发现证据不足
架构团队发现上线时才补控制
运营团队发现人工复核和例外处理不可运行

传统软件上线可以把责任拆成需求、开发、测试、变更、运维。AI 系统更复杂, 因为风险来自多个动态对象:

prompt、model、retriever、knowledge source、tool permission、agent plan、human workflow、vendor dependency 会持续变化。
AI output 可能进入客户沟通、案件记录、信用建议、AML narrative、KYC decision support 或员工知识检索。
控制不是单点审批, 而是从 intake、design、pilot、release、scale、change、incident、retirement 贯穿生命周期。
风险挑战不是阻断创新, 而是让第一线能在可证明的边界内拥有产品和运营责任。

Three Lines model 对 AI 产品与架构治理的价值:

角色	没有 Three Lines 时	有 Three Lines operating model 后
AI 产品负责人	到上线评审才发现谁能 approve 不清楚	从 intake 就知道哪些 gate 由第一线决定、哪些需要第二线 challenge、哪些证据会被第三线抽查
需求与流程负责人	需求写了 HITL、日志和审批, 但没有 owner 和 issue route	每个 control objective 都有 owner、evidence object、failure condition 和 management action route
产品架构负责人	架构图只有 RAG / Agent / API, 没有治理接口	架构中显式包含 policy decision、evidence collection、issue register、attestation 和 audit access pattern
Risk / Compliance	反复参与项目会议, 却被当成共同 owner	second line 明确负责 policy interpretation、independent challenge、risk acceptance advice 和 issue severity challenge
Internal Audit	事后发现证据散落在 Jira、Confluence、日志和邮件	third line 可以基于 evidence packet、issue aging、gate decisions 和 management action tracking 做独立 assurance
企业架构负责人	AI 平台和业务 use case 分散治理	architecture review board 将 Three Lines artifacts 嵌入 ADR、control catalog、reference architecture 和 release gate

核心转变:

from committee-based approval
to lifecycle decision architecture

from ownerless evidence
to control owner + evidence owner + challenge owner

from "risk signed off"
to first-line decision + second-line challenge + third-line assurance

from project governance
to operating model with issue management and action tracking

架构模型/核心原理

flowchart LR
  A[AI Use Case Intake] --> B[Risk Tiering and Scope]
  B --> C[Lifecycle Gate Plan]
  C --> D[First Line Product / Ops Ownership]
  C --> E[Second Line Risk / Compliance Challenge]
  C --> F[Third Line Internal Audit Assurance]

  D --> G[Control Ownership]
  E --> H[Challenge Memo / Conditions]
  F --> I[Assurance Plan / Findings]

  G --> J[Evidence Forum]
  H --> J
  I --> J

  J --> K[Gate Decision Record]
  J --> L[Issue Register]
  L --> M[Management Action Tracking]
  M --> N[Escalation / Risk Acceptance / Closure]

  K --> O[ADR and Architecture Governance]
  N --> O
  O --> P[Release / Scale / Change / Retire]

ASCII 版:

AI use case
  -> lifecycle gate
  -> first-line decision owner
  -> second-line challenge owner
  -> third-line assurance view
  -> evidence forum
  -> issue/action tracking
  -> architecture decision record
  -> release, scale, change or stop decision

三道防线不是三层审批, 而是三种不同 accountability:

Line	核心责任	对 AI 的关键问题
First line	Own and manage risk in product and operations	业务是否愿意在已知边界、控制和残余风险下上线并运营?
Second line	Set risk policy, challenge, monitor and advise	控制设计、证据和残余风险是否满足 policy 和风险偏好?
Third line	Provide independent assurance	治理、控制和 issue remediation 是否可被独立验证?

关键机制

3.1 Operating Model Objects

AI Three Lines operating model 不是一张 RACI 表, 至少包含十个对象:

Object	Definition	Owner	Evidence
AI use case record	业务目标、用户、数据、模型、自动化边界、客户影响和风险等级	First line product / business owner	inventory record、risk tier worksheet
Lifecycle gate map	intake、design、pilot、release、scale、change、retire 的 gate 和 decision rights	Governance office + EA	gate calendar、decision matrix
Control ownership map	每个 control objective 的设计、运行、证据和缺陷 owner	First line control owner	control matrix、owner attestation
Second-line challenge memo	风险、合规、隐私、安全或模型风险对设计和证据的独立挑战	Second line function	challenge memo、conditions、residual concerns
Evidence packet	支撑 gate decision 的最小充分证据集合	First line evidence owner	eval summary、ADR、policy decisions、issue log
Evidence forum	跨线审阅证据、争议和 gate readiness 的运行会议	Governance lead	agenda、minutes、decision record
Issue register	缺陷、控制失败、证据不足、policy deviation 和 unresolved challenge	Issue owner + governance office	severity、owner、due date、status
Management action plan	对 issue 的整改动作、验收证据、延期和关闭依据	First line action owner	action tracker、closure evidence
Escalation path	超过权限、逾期、残余风险过高或跨域争议的升级路径	Governance lead	escalation record、risk acceptance record
Architecture governance link	将 gate、control、evidence 和 issue 嵌入 ADR、ARB、reference architecture	企业架构责任	ADR、architecture review minutes

3.2 Three Lines Role Model

Area	First line product / ops	Second line risk / compliance	Third line internal audit
Use case ownership	Own business objective, user journey, operational process, control operation and residual risk proposal	Challenge risk tier, policy fit, control adequacy and evidence sufficiency	Assess whether governance and controls are designed and operating as represented
Control ownership	Design and operate controls embedded in workflow, platform and SOP	Define standards, challenge control design, review exceptions and acceptance rationale	Test selected controls and issue remediation independently
Evidence ownership	Produce and maintain evidence packet for gates and operations	Challenge evidence quality, completeness, relevance and expiry	Use evidence for assurance planning, sampling and findings
Decision rights	Decide go / no-go within delegated authority after challenge and conditions	Recommend, condition, object or escalate based on policy and risk appetite	Does not approve release; provides independent assurance and findings
Issue management	Own remediation, closure evidence and operational fix	Challenge severity, due date, closure sufficiency and repeat issue pattern	Validate management action closure where in audit scope
Architecture integration	Ensure solution design implements required controls and evidence events	Challenge architecture against policy, risk appetite and control objectives	Review whether architecture governance is consistently applied

3.3 Control Ownership Model

Every AI control should have four ownership fields:

Field	Meaning	Example
Control owner	Accountable for control design and operation	Contact center operations owner owns answer approval workflow
Evidence owner	Accountable for producing and retaining evidence	AI platform owner produces eval result and trace extract
Challenge owner	Accountable for second-line challenge	Compliance challenges regulated content control
Closure approver	Accountable for accepting action closure	Governance chair closes condition after evidence review

Weak control wording:

Compliance signs off the chatbot.

Strong control wording:

The contact center operations owner owns the controlled rollout and answer-review workflow. Compliance challenges whether regulated-content restrictions and escalation routing meet policy. The AI platform owner produces eval and trace evidence. Internal audit may later test whether the workflow operated as represented.

Decision Rights and Lifecycle Gates

4.1 Lifecycle Decision Matrix

Gate	Primary decision	First line decision right	Second line challenge right	Third line assurance role	Required evidence
Intake	Is this a registered AI use case worth assessment?	Sponsor accepts product scope and business owner	Challenge whether AI inventory, risk tier and policy scope are complete	Observe governance design if in audit universe	use case record, data/model/vendor summary, customer impact note
Design	Is architecture and control design fit for pilot?	Product and architecture owners decide design proposal and control owner	Challenge control objectives, policy interpretation and evidence plan	Review governance artifacts for future assurance planning	solution architecture, control matrix, ADR draft, evidence plan
Pilot	Can limited pilot proceed?	Business owner accepts controlled pilot boundary	Challenge pilot criteria, population, restrictions and exit rule	May review pilot governance if high risk	pilot plan, eval summary, operations SOP, issue log
Release	Can production release proceed within delegated authority?	Product / ops owner makes go / no-go recommendation and accepts residual risk proposal	Condition, object or escalate if residual risk or evidence gaps exceed policy	Does not sign release; may note assurance concerns separately	release packet, challenge memo, open issue disposition, rollback plan
Scale	Can traffic, automation or business scope expand?	Business owner requests expansion based on value and control evidence	Challenge whether evidence remains valid under scale and new population	Use scale as trigger for audit planning	scale memo, control performance, issue aging, operational capacity evidence
Material change	Can model, prompt, RAG source, tool or vendor change proceed?	Change owner decides within approved change class	Challenge change classification, impacted controls and regression evidence	Review change governance effectiveness if sampled	change impact assessment, regression eval, ADR update, approval record
Incident / stop	Should the system degrade, pause, rollback or escalate?	Incident commander and business owner execute stop rule	Challenge severity, customer impact and remediation sufficiency	Independently review incident handling after the fact	incident record, replay packet, action plan, closure evidence
Retire	Can use case, model or vendor dependency be decommissioned?	Product owner retires capability and data/evidence retention plan	Challenge retention, customer impact and regulatory obligations	May test retirement control if material	retirement ADR, retention record, residual obligation register

4.2 Decision Rights Rules

Decision rights should be written as rules, not personalities:

Rule	Practical expression
First line owns the risk decision	Product / operations leader cannot outsource go-live responsibility to risk, compliance or audit.
Second line owns challenge and escalation	Risk and compliance can condition, object or escalate, but should not become delivery owner.
Third line owns independent assurance	Internal audit should not approve releases or design controls it later audits.
Gate decision must bind evidence version	A gate decision references exact evidence versions, open issue dispositions and conditions.
Conditions must have expiry and owner	A conditional go cannot be an indefinite waiver.
Material change reopens decision rights	Prompt, model, RAG corpus, tool permission, automation level or vendor changes can trigger re-review.
Dispute route must be explicit	If first and second line disagree, escalation path and acceptance authority are known before the gate.

4.3 Decision Record Schema

Field	Description
Decision id	Unique gate decision identifier
Use case / version	AI use case, model, prompt, workflow, policy and architecture versions
Gate	intake, design, pilot, release, scale, change, incident or retire
Decision	go, no-go, conditional go, reduce scope, escalate, pause, rollback or retire
First line accountable owner	Business or operations owner accepting the decision
Second line position	no objection, condition, objection, escalation, policy exception required
Third line note	assurance planned, prior finding relevant, no role in release approval
Evidence packet	links or ids for evidence set used in decision
Open issues	accepted, blocker, deferred with due date, escalated
Conditions	condition, owner, due date, closure evidence
Rationale	business benefit, residual risk, control readiness, operational readiness
Review trigger	traffic threshold, model change, incident, issue aging, policy update

Assurance Evidence Forum and Issue Management

5.1 Evidence Forum Purpose

Evidence forum 是一个工作机制, 不是审批仪式。它回答:

Gate decision 需要哪些证据才足够。
Evidence 是否与 claim、control、risk、architecture 和 operating process 对齐。
哪些 second-line challenge 未关闭。
哪些 issue 是 release blocker、conditional release、post-release action 或 risk acceptance。
哪些 architecture decision 需要进入 ADR / ARB。
哪些 management action 已超期、重复发生或需要升级。

Evidence forum 的标准输入:

Input	Owner	Quality check
Use case and risk tier	业务负责人 / governance office	scope、customer impact、automation boundary 清楚
Architecture view	产品架构 / EA	RAG、agent、copilot、policy、evidence、ops integration 清楚
Control matrix	First line control owner	control objective、activity、owner、frequency、failure condition 清楚
Eval and test summary	AI platform / delivery team	sample scope、threshold、failure disposition 清楚
Challenge memo	Second line	conditions、objections、policy exceptions 清楚
Issue/action log	Issue owners	severity、owner、due date、closure evidence 清楚
ADR / decision record	架构负责人 / governance lead	decision, rationale, tradeoff, review trigger 清楚

5.2 Issue Taxonomy

Issue type	Example	Default owner	Gate impact
Evidence gap	AML copilot release packet lacks source-span evidence for narrative drafts	Evidence owner	conditional or blocker depending risk
Control design gap	Enterprise knowledge assistant cannot restrict HR policy answers by entitlement	Control owner + architecture owner	blocker for sensitive corpus
Control operation failure	KYC onboarding follow-up drafts bypass mandatory reviewer queue	Operations owner	pause, rollback or limited release
Policy deviation	Vendor model uses data processing terms outside approved configuration	Vendor / procurement owner	escalate to risk acceptance authority
Challenge unresolved	Compliance objects to regulated advice phrasing in contact center script	Governance lead	escalate or no-go
Issue aging	Same citation-quality issue remains open across three release cycles	Action owner + sponsor	escalation
Repeat finding	Audit previously found weak gate evidence for similar use case	Governance office	enhanced evidence requirement

5.3 Management Action Tracking

Management action must be more specific than "fix before launch":

Field	Example
Action id	ACT-AML-2026-061
Linked issue	ISS-AML-2026-044: missing source-span evidence for suspicious activity narrative
Action statement	Add narrative source-span capture for every paragraph saved to case record and produce 30-case sample evidence
Owner	AML platform product owner
Due date	2026-07-15
Acceptance criteria	100% of sampled saved narratives include source ids, retrieved passage ids, analyst edit diff and approval event
Closure evidence	event extract, sample workbook, reviewer sign-off, updated ADR
Second-line closure view	Financial crime compliance confirms evidence sufficiency for gate condition
Residual concern	Low residual concern; monitor monthly sample for first 90 days
Reopen trigger	Any production narrative saved without source-span event

5.4 Escalation Patterns

Escalation should be based on thresholds:

Trigger	Escalation path	Likely outcome
Release blocker not closed by gate date	Governance chair -> business sponsor -> risk acceptance authority	no-go, scope reduction or formal exception
First / second line disagreement on residual risk	Governance chair -> designated risk committee / executive owner	decision with documented rationale
Issue overdue beyond one cycle	Action owner -> sponsor -> portfolio governance	reprioritize funding or pause scale
Repeat issue across use cases	Governance office -> enterprise architecture / platform owner	platform pattern, control standard update
Audit finding overdue	Management action owner -> audit issue tracking route	formal audit action escalation
Material vendor change without evidence	Vendor owner -> third-party risk -> architecture review	freeze change, alternate provider, exit action

证据与控制

7.1 Metric Families

Metric family	Purpose	Example metrics	Three Lines usage
Value KPI	Prove business value	AHT reduction, analyst prep time reduction, onboarding cycle time, search deflection	First line uses for scale recommendation
Risk KRI	Identify exposure and harm trend	unsupported answer rate, high-risk escalation miss, override volume, complaint linkage	Second line challenges threshold and trend
Control KCI	Prove control operation	approval binding rate, evidence completeness, policy decision coverage, issue closure timeliness	First / second line review operating effectiveness
Evidence quality	Prove auditability	packet completeness, stale evidence count, sample trace reconstructability	Third line and governance office use for assurance readiness
Architecture fitness	Prove design remains governable	trace coverage, policy enforcement point coverage, tool allowlist drift, knowledge-source freshness	EA / platform owner use for architecture gate
Issue management	Prove remediation discipline	overdue actions, repeat issue rate, reopened issue rate, conditional-go aging	Governance office escalates

7.2 Control-to-Evidence Pattern

Control objective	Control activity	Evidence object	Owner	Gate signal
AI use case has accountable first-line owner	Inventory requires sponsor, process owner, control owner and evidence owner	use case record, owner attestation	业务负责人 / governance office	Missing owner blocks design gate
Risk challenge occurs before release	Second line challenge memo required for high-risk use cases	challenge memo with conditions and objections	Risk / compliance	Unresolved blocker prevents release
Evidence packet supports gate decision	Gate decision references exact evidence ids and issue dispositions	evidence packet index, decision record	Governance lead	Packet mismatch triggers rework
Controls are operationally owned	Each control has operation owner, failure condition and evidence cadence	control matrix	First line control owner	No owner or cadence blocks release
Issues become managed actions	Every material issue has action owner, due date, closure evidence and reopen trigger	issue/action log	Action owner	Overdue issue escalates
Architecture decisions remain traceable	Material gate conditions become ADR entries and review triggers	ADR, ARB minutes	产品架构 / EA	No ADR for material control tradeoff blocks architecture approval

7.3 Evidence Sufficiency Levels

Level	Evidence posture	Suitable for
Level 1: assertion	Team states control exists, no sample or trace	Early exploration only
Level 2: design evidence	Architecture, SOP and control design documented	Design gate
Level 3: test evidence	Eval, walkthrough, negative test or dry run proves design	Pilot and release gate
Level 4: operating evidence	Production logs, samples and issue closure show control ran	Scale and management action closure
Level 5: independent assurance evidence	Internal audit or independent assurance validates selected claims	Audit universe, high-risk review, post-incident review

金融零售/AI产品场景

Scenario	First line ownership	Second line challenge	Third line assurance angle	Decision-right nuance
GenAI contact center	Contact center owner owns agent assist scope, call-flow integration, escalation SOP and quality sampling	Compliance challenges regulated content, complaint risk, vulnerable customer escalation and evidence quality	Audit may test whether agents followed approved script / escalation workflow and whether evidence supports management statements	Release gate may allow internal agent assist before customer-facing autonomous response
AML copilot	Financial crime operations owns analyst workflow, case narrative quality and final disposition process	Financial crime compliance challenges typology coverage, SAR boundary, source evidence and escalation rules	Audit may sample cases to test whether AI-generated narratives were reviewed and disposition remained human-owned	Gate must bind AI draft evidence to case record and analyst approval
Credit decision support	Credit product / underwriting owns advisory scope and lending workflow	Credit risk / compliance challenge adverse action, fairness, policy consistency and decision boundary	Audit may test governance over decision-support use and issue remediation	Decision support may be approved while final credit decision remains outside AI authority
KYC onboarding	Onboarding operations owns document workflow, customer follow-up and exception handling	Compliance challenges CDD / EDD policy interpretation, false reject risk and evidence retention	Audit may review whether exceptions and manual overrides are logged and remediated	Gate should separate document classification, missing-info draft and actual rejection decision
AI vendor model	Vendor owner / platform owner owns integration, configuration, SLA and exit readiness	Third-party risk, privacy, security and legal challenge data use, subprocessors, incident notice and model update controls	Audit may review third-party governance and management action closure	Material model update or data term change can trigger gate re-review
Enterprise knowledge assistant	Knowledge owner and IT service owner own corpus, entitlement, search quality and usage	Compliance / data governance challenge approved-source boundaries, retention and sensitive-data leakage	Audit may test entitlement, source governance and issue handling	Low-risk internal answer may scale faster than HR, legal or regulated policy corpus

Advanced scenario notes:

GenAI contact center: first line owns quality and operational readiness; second line challenges what happens when a response crosses into regulated advice or complaint handling; architecture governance ensures transcript, answer, source, escalation and reviewer evidence are capturable.
AML copilot: do not define success only by analyst productivity. Gate evidence must show case narrative source support, analyst edit/approval, typology coverage and issue route for unsupported claims.
Credit decision support: decision rights must distinguish recommendation, explanation, policy lookup, affordability calculation and final decision. The evidence forum should test whether business users understand the boundary.
KYC onboarding: false reject, false accept and customer friction issues need separate owners and escalation paths. A single "KYC AI approved" label hides materially different control obligations.
AI vendor model: vendor onboarding is not a one-time procurement event. Model update notice, incident notice, data use terms, fallback and exit evidence are part of lifecycle gates.
Enterprise knowledge assistant: entitlement-aware retrieval, approved-source lifecycle and issue management matter more than generic answer quality.

反模式

Anti-pattern	What it looks like	Failure mode	Better design
"Risk signed off" language	Release note says risk approved the system	First line loses ownership and second line becomes implied co-owner	Record first-line decision, second-line challenge position and residual-risk rationale separately
Audit as release approver	Internal audit invited to approve go-live	Audit independence and assurance role become blurred	Audit may observe or use artifacts later, but does not approve production release
Evidence dump	80-page pack of screenshots and logs	Reviewers cannot connect evidence to controls or decision rights	Evidence index maps claim -> control -> test -> evidence -> owner
Gate theater	Committee meeting happens after decision already made	Challenge has no effect and issues become political	Gate entry criteria, blocker rules and escalation path defined before meeting
Ownerless conditions	Conditional go includes "improve monitoring"	Action never closes or cannot be tested	Each condition has action owner, due date, acceptance criteria and closure evidence
Second line delivery ownership	Risk function writes SOP or configures controls	Independent challenge weakens	First line builds; second line sets standards and challenges evidence
Architecture blind spot	RAG / agent architecture ignores evidence and policy points	Controls cannot be proven after release	Add policy decision, evidence event, trace and issue-route components to reference architecture
Issue aging normalization	Conditional issues stay open across releases	Temporary risk becomes permanent operating mode	Aging thresholds trigger escalation or scope reduction
Change bypass	Prompt or corpus changes treated as minor content edit	Prior evidence becomes invalid	Materiality rules reopen gate for model, prompt, RAG, tool and vendor changes
Single forum overload	One committee handles intake, design, release, incident and audit issues	Decision rights get confused	Separate operating cadence by gate, but keep common issue/action register

最终心智模型

AI Three Lines governance 不是多加审批，而是把第一线决策、第二线挑战、第三线 assurance 连接到同一条 lifecycle evidence chain。技术架构必须显式包含 policy decision interface、evidence event interface、issue/action interface 和 architecture decision interface；否则治理只能停留在会议纪要和上线前补材料。

Business workflow / Copilot UI
  -> entitlement and role context
  -> RAG retrieval / knowledge source governance
  -> model / prompt / policy orchestration
  -> agent tool gateway / action boundary
  -> eval and test evidence
  -> evidence collector / trace store
  -> control matrix / issue register
  -> lifecycle gate / ADR / architecture review
  -> Three Lines evidence forum

Architecture layer	First line concern	Second line challenge	Third line assurance angle	Required artifact
RAG	Approved sources, answer usefulness, operational ownership of corpus	Source approval, citation quality, sensitive data and policy currency	Test whether source governance and issue remediation operate	source inventory, index version, retrieval eval, citation sample
Agent	Allowed actions, tool boundaries, operational fallback	Automation level, customer impact, exception rules and escalation	Test selected tool actions, approval evidence and issue closure	tool registry, policy decisions, action trace, approval record
Copilot UX	Human workflow, review ergonomics, adoption and override capture	User understanding, over-reliance, regulated-content boundary	Test whether users followed approved workflow	UX state model, review SOP, edit diff, training evidence
Eval	Release criteria, workflow-specific tests, defect disposition	Scenario coverage, threshold appropriateness, unresolved high-risk failures	Review evidence sufficiency, reproducibility and action closure	eval contract, test report, failure log, closure evidence
Governance	Gate readiness, issue management, ADR and control ownership	Policy alignment, residual risk, escalation and conditions	Independent assurance over governance process and controls	decision record, challenge memo, issue/action log, ADR
Platform	Evidence capture, policy enforcement, logging, retention	Data protection, vendor, security and resilience requirements	Test platform control design and operation	reference architecture, control implementation, access logs

最终判断标准：第一线不能把上线责任外包给风险合规，第二线不能变成交付 owner，第三线不能做 release approver。Gate decision 必须绑定证据版本、open issue disposition、conditions、review trigger 和 escalation route。Material change 不是内容小改，而是任何会改变 model、prompt、RAG corpus、tool permission、automation level、vendor dependency 或 customer-impacting workflow 的变化，都可能重新打开治理门禁。

Source Anchors

These anchors provide governance language and operating-model structure. They do not create automatic compliance, audit reliance or production approval.

Source	Official link	How this note uses it
IIA Three Lines Model	https://www.theiia.org/en/content/position-papers/2020/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense/	Anchors the separation between management ownership, risk/compliance challenge and internal audit assurance. （2020-07）
Basel Committee Corporate Governance Principles for Banks	https://www.bis.org/bcbs/publ/d328.htm	Anchors board / senior management governance discipline, risk management, control environment and internal audit expectations for banks. （2015-07）
COSO Internal Control Overview	https://www.coso.org/guidance-on-ic	Anchors control environment, risk assessment, control activities, information/communication and monitoring concepts. （汇总页无单一发布日期，访问日期: 2026-07-01）
NIST AI Risk Management Framework	https://www.nist.gov/itl/ai-risk-management-framework	Anchors Govern / Map / Measure / Manage thinking for AI risk lifecycle, evidence and management action. （AI RMF 1.0 发布 2023-01；生态持续更新中，见文末 SOTA 检查）
ISO/IEC 42001 AI Management System	https://www.iso.org/standard/81230.html	Anchors AI management system scope, policy, planning, operation, performance evaluation and improvement. （ISO/IEC 42001:2023，2023-12）
ISO/IEC 23894 AI Risk Management	https://www.iso.org/standard/77304.html	Anchors AI risk management terminology and risk treatment structure for AI systems. （ISO/IEC 23894:2023，2023-02）

SOTA 检查 (2026-07-01)

Three Lines 用于 AI 治理仍是当前主流框架，未被替代：IIA Three Lines Model（2020-07）依旧是行业锚点，学术侧的映射工作是 arXiv 2212.08364 "Three lines of defense against risks from AI"（2022-12，后发表于 AI & Society），2026 年的 GRC 行业综述（如 Trustible、CyberSaint 2026 年框架盘点）仍以 3LoD 作为 AI 治理组织模型的默认起点。本篇的核心框架性结论——decision rights 拆分、lifecycle gate 绑定证据版本、issue/action tracking、第三线不做 release approver——属于不随模型版本过时的 operating-model 结构，仍然成立。
第三线（assurance）生态在 2025 年已标准化：ISO/IEC 42001:2023（2023-12，AIMS）之外，新增 ISO/IEC 42005:2025（2025-04 发布，AI system impact assessment，可直接支撑本篇的 evidence packet / risk tiering 对象）和 ISO/IEC 42006:2025（2025 年发布，规定 AIMS 审计与认证机构的资质要求）。这意味着本篇 "Level 5: independent assurance evidence" 现在有了可引用的认证审计标准，第三线抽样验证不再只是内部实践。
NIST AI RMF 生态持续扩展而非被替代：AI RMF 1.0（2023-01）+ Generative AI Profile NIST AI 600-1（2024-07）仍是美国侧主线；2025-03 有面向生成式 AI 风险、供应链与第三方模型评估的更新，2026 年内预期落地 RMF 1.1 补充指引与 SP 800-53 AI control overlays。本篇的 Govern/Map/Measure/Manage 引用方式不受影响，但做美国侧案例时应叠加 600-1 的 GenAI 风险清单。
EU AI Act 时间线已变（本篇写作时已知，读者必须用新时间线）：2026-05-07 Digital Omnibus 达成临时政治协议，Annex III 独立高风险系统义务推迟至 2027-12-02，Annex I 嵌入受监管产品的 AI 推迟至 2028-08-02；GPAI 义务已于 2025-08-02 生效。任何把 "2026-08 高风险合规" 当作 gate deadline 的旧材料都已过时；本篇 lifecycle gate / material change 机制本身与该时间线解耦，仍可直接使用。
与库内已有带日期资产的衔接：本篇的操作手册版是 docs/AI_THREE_LINES_GOVERNANCE_DECISION_RIGHTS_ASSURANCE_PLAYBOOK.md；工程落地侧可交叉参考 AIPA-120（2026-06 完成）中的 docs/aipa/day49-article50-compliance.md（AI Act Article 50 透明度合规）、docs/aipa/day53-risk-gateway.md（第二线事中风控网关的技术实现）与 docs/aipa/day74-audit-trail-otel.md（OTel 审计轨迹，即本篇 evidence event interface 的可运行版本）。
需要持续盯的漂移点：agentic AI（多步工具调用、跨系统 action）正把治理重心从 "模型输出审批" 移向 "工具权限与 action boundary 的事中控制"，本篇 4.1 表中 "Material change: tool permission / automation level 变更重开 gate" 是对该趋势的正确抽象；后续若 IIA 或 Basel 发布 agentic AI 专项指引（截至 2026-07-01 尚未见正式文件），应优先并入第二线 challenge 清单。