AI Stakeholder Decision Coalition：影响力风险与对齐架构
AI stakeholder alignment 不是软性沟通, 而是交付架构的一部分。金融零售 AI 项目会同时触达客户权益、员工工作流、模型风险、信息安全、隐私、合规、内审、供应商、运营容量和品牌信任。成熟做法不是维护 stakeholder list, 而是把 authority、concern、incentive、harm、forum、requirement、control 和 evide
AI Stakeholder Decision Coalition / Influence Risk / Alignment Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_STAKEHOLDER_DECISION_COALITION_INFLUENCE_RISK_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
核心导读
AI stakeholder alignment 不是软性沟通, 而是交付架构的一部分。金融零售 AI 项目会同时触达客户权益、员工工作流、模型风险、信息安全、隐私、合规、内审、供应商、运营容量和品牌信任。成熟做法不是维护 stakeholder list, 而是把 authority、concern、incentive、harm、forum、requirement、control 和 evidence 组织成 decision coalition architecture, 让不同利益相关方的关切可以被架构视图、控制机制和证据包验证。
重要说明: 本文是学习、作品集和内部架构训练材料, 不构成法律意见、监管解释、审计意见、模型验证结论、风险接受决定、组织政治建议或正式治理授权。正式项目中的决策权、审批权、职责边界、风险偏好、客户影响判断、记录保留、合规要求、劳动关系、第三方责任和上线批准必须由机构授权角色结合司法辖区、产品、客户群、内部政策和监管关系确认。访问日期沿用 2026-06-30。
0. Source Anchors and Reading Boundary
| Source | Official link | 本文使用方式 |
|---|---|---|
| ISO/IEC/IEEE 42010 Architecture Description | https://www.iso.org/standard/74393.html | 用 stakeholder、concern、architecture viewpoint、architecture view、correspondence 和 rationale 组织 concern 到架构视图的映射。 |
| ISO/IEC/IEEE 29148 Requirements Engineering | https://www.iso.org/standard/72089.html | 用 stakeholder need、requirements lifecycle、quality 和 traceability 组织 concern 到 requirement / control / evidence 的链路。 |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 stakeholder risk identification、measurement、management 和持续改进。 |
| ISO/IEC 42001 AI Management System | https://www.iso.org/standard/81230.html | 用 AI management system、roles、planning、operation、performance evaluation 和 internal audit 组织 forums 与 evidence discipline。 |
本文默认读者已经理解金融零售组织中的产品、运营、风险、合规、法务、信息安全、内审、技术和一线团队如何共同影响系统上线。 主线不是基础 stakeholder 管理, 而是如何把复杂权力和关切转成可治理的 AI architecture work product。
1. 核心问题: AI 项目为什么卡在 alignment
AI 项目失败经常不是模型不够强, 而是团队没有清楚回答谁能批准、阻断、出资、运营、审计、采用或被伤害。 一个看似简单的 copilot、KYC AI、AML triage 或 personalized pricing, 可能同时改变客户资金访问、开户资格、费率、解释权、员工复核责任、模型风险、记录保留、第三方责任和品牌信任。
低成熟度表达会把问题写成:
We need stakeholder buy-in.
We need more communication.
Risk team is slowing the project.
Operations is not supportive.
成熟表达会把它改写成 decision architecture:
Which decisions are required?
Who can approve, block, fund, operate, audit, adopt or be harmed?
What concerns must the architecture answer?
Which views, requirements, controls and evidence satisfy those concerns?
Which forums resolve conflicts and exceptions?
What signals reveal hidden veto or adoption resistance before release is blocked?
AI stakeholder alignment 的目标不是让所有人同意。 目标是让重要 concern 被显性记录、可追溯转译、进入正确 forum, 并用证据决定是否继续、限制、补救或停止。
2. 方法框架: Coalition Alignment Is Architecture
成熟的 AI stakeholder work 应沿着以下链条组织:
business outcome and AI use case
-> stakeholder ontology
-> decision-rights map
-> concern inventory
-> concern-to-viewpoint mapping
-> requirement / control / evidence traceability
-> coalition graph and influence risk signals
-> forum architecture and escalation paths
-> communication artifacts
-> decision log and evidence binder
-> adoption and monitoring feedback loop
这条链把人的权力、利益、顾虑和受害可能性, 转成系统必须回答的视图、需求、控制和证据。 它不把 stakeholder 当成通讯录, 而把 stakeholder 看成交付系统中的决策依赖。
| Concern type | 示例 | 架构产物 |
|---|---|---|
| Business value | AI agent 是否降低 AHT 或提升 straight-through processing | value hypothesis、baseline metric、benefit evidence |
| Customer harm | KYC AI 是否误拒新客或弱势客户 | harm model、recourse journey、segment eval、complaint monitoring |
| Risk appetite | Personalized pricing 是否越过公平、合规或声誉边界 | risk appetite interpretation、policy constraints、decision gate |
| Security | Agent tool 是否越权查询或执行写操作 | tool action tier、policy engine、approval gateway、action ledger |
| Model risk | AML triage 是否漏掉高风险 alert | model risk tier、eval contract、human review、override analysis |
| Legal / compliance | Collections hardship AI 是否生成不当承诺 | approved language、citation、review queue、record retention |
| Operations | 新流程是否把队列压垮 | capacity model、fallback runbook、training and support evidence |
| Audit | 上线后能否证明谁批准了什么 | decision log、evidence binder、versioned artifacts |
高质量架构不是消除冲突, 而是让冲突进入正确 forum, 用正确证据解决。
3. Stakeholder Ontology and Decision Rights
Stakeholder 不是一个角色标签, 而是与 AI initiative 的决策、责任、影响和证据关系。 一个人或团队可能同时是 funder、reviewer、operator 和 hidden veto。
| Stakeholder type | 定义 | 常见金融零售角色 | 关键问题 |
|---|---|---|---|
| Decision owner | 对某类决策拥有最终批准或拒绝权 | Product GM、Business Owner、Model Risk Committee、Risk Executive | 这件事谁能说 yes 或 no? |
| Funder | 控制预算、人员或平台容量 | Portfolio Council、CFO delegate、Transformation Office | 资金和 capacity 条件是什么? |
| Blocker | 能通过 policy、risk、security、legal、architecture 或 operations 阻止上线 | CISO、CRO、Legal、Compliance、Architecture Board、Operations Readiness | block condition 是什么? |
| Influencer | 不拥有正式批准权, 但能改变 sponsor、用户或 reviewer 判断 | Sales leader、Branch leader、Support director、Data science lead | 他们影响什么叙事或 adoption? |
| Reviewer | 负责挑战设计、证据或控制, 但不一定拥有最终决策 | Internal Audit、Independent Model Validation、Privacy、Accessibility | 他们需要看什么 evidence? |
| Operator | 上线后运行流程或控制的人 | AML analyst、KYC reviewer、collections agent、call center supervisor | 设计会如何改变他们的工作? |
| Adopter | 必须实际使用或接受系统的人 | Sales RM、support agent、operations analyst、customer | 他们为什么会采用或抵抗? |
| Harmed party | 可能因错误、偏差、延迟、误导或自动化扩大而受损的人 | Applicant、customer、vulnerable customer、frontline employee | 伤害如何预防、发现、补救? |
| Evidence owner | 负责生成、保管或证明证据的人 | QA、EvalOps、Platform、Risk、Records、Release Manager | 证据是否可复现、版本化、可审计? |
| Hidden veto | 没有显性 RACI, 但能在晚期通过 informal gate 阻断的人或团队 | Legal specialist、data owner、vendor risk reviewer、channel operations | 哪个未显性约束会晚期爆发? |
最低要求是区分:
decision owner != influencer != reviewer != operator != harmed party
Decision-rights map 要补足 RACI 的盲区。 RACI 说明谁参与工作, 但不说明谁能改变 gate 结果。
| Decision right | 决策对象 | Evidence required |
|---|---|---|
| Approve | 是否进入 discovery、pilot、release、scale | business case、risk tier、architecture pack、eval result |
| Block | 哪些条件不满足时不能继续 | blocker criteria、open gaps、risk memo |
| Fund | 预算、平台 capacity、SME time | value case、cost-to-serve、delivery roadmap |
| Operate | 谁运行流程、监控、fallback 和 incident response | runbook、training、capacity model、SLO |
| Audit / assure | 是否能独立检验证据和控制 | evidence binder、decision log、control matrix |
| Adopt | 谁真正使用、推荐或接受系统 | adoption plan、training、feedback、override metrics |
| Be protected | 如何避免、发现和补救 harm | harm model、recourse journey、monitoring and remediation |
| Decision | Owner | Reviewers | Operators | Harmed parties | Forum | Entry evidence | Exit decision |
|---|---|---|---|---|---|---|---|
| Move KYC AI to pilot | Retail Onboarding Owner | Legal、Privacy、CISO、Model Risk | KYC Ops | New applicants | AI Pilot Gate | impact assessment、eval pack、runbook | approve / limited pilot / hold |
| Enable agent write tool | Digital Servicing Owner | CISO、Operational Risk、Compliance | Contact center supervisors | Customers and agents | Tool Action Review | tool tier、dry-run evidence、approval flow | allow / require review / deny |
| Scale AML triage | AML Program Owner | Model Risk、Compliance、Audit | AML operations | Bank、customers、regulators | Financial Crime AI Committee | recall eval、override analysis、SAR boundary | scale / restrict / retrain |
If a gate has no owner、forum、entry evidence or exit decision, it is not governance; it is hidden delivery risk.
4. Concern to Viewpoint, Requirement, Control and Evidence
ISO 42010 的实用价值在于先问 stakeholder concern, 再决定需要哪些 architecture viewpoints。 AI stakeholder coalition 需要一组视图, 而不是一张总图。
| Concern | Viewpoint | View contents | Decision supported |
|---|---|---|---|
| Who is affected and how? | Stakeholder impact view | roles、segments、harmed parties、benefits、burdens | scope、impact tier、adoption design |
| Who decides what? | Decision-rights view | owner、influencer、reviewer、operator、blocker、forum | governance、escalation、gate ownership |
| What can AI do? | Human accountability and action view | AI role、human review、approval、prohibited actions | AI autonomy boundary |
| What risks matter? | Risk and harm view | failure modes、severity、likelihood、controls | risk acceptance and monitoring |
| What requirements express concerns? | Requirements traceability view | concern -> need -> requirement -> acceptance criterion | backlog and scope baseline |
| What controls answer concerns? | Control architecture view | policy、control objective、runtime control、manual control | control design and testing |
| What evidence proves readiness? | Evidence binder view | source、version、eval、approval、monitoring、decision log | release certification、audit |
| Where will resistance occur? | Adoption and operations view | workflow change、incentives、training、capacity、override | adoption plan、rollout sequencing |
Viewpoint design asks which concern is being answered, what decision needs this view, which evidence must accompany it, who can challenge it, and what change would invalidate it. If a concern only maps to "we will communicate", the architecture remains incomplete.
Stakeholder concerns should trace through requirements and controls:
stakeholder concern
-> stakeholder need
-> business / system / data / control requirement
-> acceptance criterion
-> architecture decision
-> control implementation
-> eval / test / review evidence
-> release or exception decision
-> production monitoring signal
Example: AI agent tool for customer support.
| Trace object | Example |
|---|---|
| Concern | CISO worries agent can update customer profile without proper authorization. |
| Need | High-risk tool actions must be mediated by policy、identity、approval and audit. |
| Requirement | Profile write actions route through a tool gateway enforcing role、action tier、dry-run preview and supervisor approval for high-impact fields. |
| Control | Tool policy engine denies unsupported action, requires approval for sensitive fields, logs request and outcome. |
| Evidence | tool catalog、action tier matrix、test traces、approval ledger、access review、incident drill. |
| Monitoring | denied action rate、approval bypass attempts、write error rate、audit log completeness. |
Example: Collections hardship AI.
| Trace object | Example |
|---|---|
| Concern | Legal and Compliance worry the AI may promise hardship relief outside approved policy. |
| Need | Customer-facing hardship language must stay inside approved policy and preserve escalation rights. |
| Requirement | Assistant cites active policy, avoids final commitment language unless authorized, and routes uncertainty to a hardship specialist. |
| Control | Approved response library、citation check、no-answer rule、human review for commitments. |
| Evidence | policy source card、eval results for prohibited phrases、reviewer samples、communication approval. |
| Monitoring | unsupported commitment rate、complaint tags、supervisor override、policy update regression. |
If a stakeholder concern cannot be traced to requirement, control and evidence, it is still an unresolved delivery risk.
5. Coalition Graph, Hidden Veto and Influence Risk
Coalition graph shows how decision influence moves through people, committees, systems, evidence and incentives. It is not gossip; it is a delivery dependency map.
AI initiative
-> decisions required
-> formal forums
-> formal decision owners
-> informal influencers
-> blockers and hidden vetoes
-> operators and adopters
-> harmed parties and advocates
-> evidence dependencies
| Node type | Examples |
|---|---|
| Decision | approve pilot、approve model、approve tool write、approve customer communication、scale rollout |
| Forum | AI governance council、model risk committee、architecture board、operations readiness review |
| Actor | CISO、CRO、Legal、Product、Sales、Ops、Support、Data Owner、Model Owner |
| Concern | privacy、fairness、operational capacity、customer harm、revenue、explainability |
| Artifact | eval report、risk memo、architecture view、runbook、customer communication pack |
| Control | policy gate、human review、access control、monitoring threshold、recourse process |
| Signal | veto risk、narrative conflict、adoption resistance、evidence gap |
Edges should state who owns decisions, who can block, who influences adoption, who operates the process, who may be harmed, which evidence is required, and which artifact satisfies which concern.
Influence risk is delivery risk created by unclear authority, conflicting incentives, weak evidence or late-stage concern discovery.
| Signal | Meaning | Response |
|---|---|---|
| "We support the idea, but..." repeated by a blocker | concern not converted to explicit gate | ask for block condition、evidence standard and decision forum |
| Different teams use different success stories | narrative conflict | create value-risk-customer narrative pack |
| Operators praise pilot but avoid daily use | adoption resistance | map workflow burden、training gap、incentive mismatch and trust issue |
| Risk team asks broad questions late | risk appetite interpretation was missing | create risk appetite translation memo and control matrix |
| Legal rewrites customer language repeatedly | policy and communication views incomplete | create approved language library and source-cited response patterns |
| Model Risk asks for slices not in eval | harmed party or segment mapping incomplete | extend eval contract and stakeholder impact view |
| CISO asks tool action details in release week | tool/action viewpoint missing | build tool tier、approval、idempotency and action ledger evidence |
| Sponsor pushes release despite evidence gaps | governance pressure | move decision to formal forum with exception record and risk owner |
Hidden veto appears when a team can block progress without being visible in the official decision map.
| Source | Example | How to expose early |
|---|---|---|
| Data owner | refuses customer transcript use because purpose and retention are unclear | source inventory with permission and purpose review |
| Records / Legal hold | blocks deletion or retraining because evidence must be retained | records and hold assessment in architecture gate |
| Channel operations | rejects rollout because staffing model is impossible | operations readiness review before pilot |
| Vendor risk | delays model provider approval | third-party risk intake at discovery |
| Accessibility reviewer | blocks customer-facing flow | inclusive design and recourse view |
| Finance | questions benefit case | baseline、unit economics and value evidence |
Misaligned incentives are architecture inputs, not character flaws.
| Incentive conflict | Financial retail example | Architecture response |
|---|---|---|
| Sales conversion vs risk control | Personalized pricing AI pushes aggressive offers | policy guardrails、offer review、fairness monitoring |
| Product speed vs model validation | KYC AI wants fast onboarding | limited pilot、staged approval、eval evidence |
| Ops efficiency vs customer recourse | Collections AI automates hardship triage | human escalation、appeal path、vulnerable customer flags |
| Cost reduction vs support quality | Agent assist reduces AHT but increases wrong answers | quality sampling、confidence threshold、training |
| Security least privilege vs agent usefulness | AI agent needs many tools | tool tiering、approval、dry-run、scoped credentials |
6. Risk Narrative, Appetite, Escalation and Forums
Risk narrative connects stakeholder concerns to executive decision. It explains what could go wrong, who could be harmed, which controls reduce risk, what residual risk remains, and who can accept it.
| Enterprise phrase | AI initiative interpretation | Requirement / control |
|---|---|---|
| Low tolerance for customer harm | No critical unsupported customer commitment in release eval | prohibited output eval、human review、complaint trigger |
| Conservative model risk posture | High-impact decisions require validation and monitoring before scale | model risk tier、independent review、drift thresholds |
| Strong privacy posture | Minimize data sent to model and log only necessary metadata | data minimization、redaction、retention、access audit |
| Operational resilience priority | AI degradation must not stop critical service | fallback workflow、manual queue capacity、kill switch |
| Fair treatment of customers | Segment harm must be measured and remediated | segment eval、fairness review、recourse path |
| Audit readiness | Decisions and evidence must be reconstructable | evidence binder、versioning、decision log |
Risk appetite memo should include use case, affected population, risk categories, appetite phrases, thresholds, prohibited outcomes, controls, evidence, residual risk owner, exception process and monitoring signal.
Escalation should be designed before conflict occurs.
| Escalation trigger | First forum | Executive forum | Evidence package |
|---|---|---|---|
| Customer harm signal | Ops/Risk incident triage | AI Governance Council / CRO delegate | incident record、impacted segment、action log |
| Security boundary unresolved | Security architecture review | CISO risk forum | threat model、data flow、access design |
| Model fitness dispute | Model risk review | Model Risk Committee | eval contract、validation report、limitations |
| Legal interpretation needed | Legal/compliance review | Legal risk committee | communication draft、policy source、affected journey |
| Operations capacity breach | Operations readiness review | Business steering committee | queue model、staffing、fallback runbook |
| Architecture exception | Architecture board | Technology risk committee | target architecture、exception、compensating controls |
| Risk appetite conflict | Risk/control forum | Enterprise risk committee | risk appetite memo、residual risk、alternatives |
| Adoption resistance | Product/Ops adoption review | Business portfolio council | usage、override、training and feedback evidence |
AI stakeholder coalition requires forums with clear mandates.
| Forum | Mandate | Typical decisions | Evidence |
|---|---|---|---|
| Product Discovery Council | value、scope、adoption、customer problem | fund discovery、shape MVP、prioritize outcomes | opportunity brief、baseline、stakeholder matrix |
| AI Architecture Review | system boundary、data、model、RAG、tools、controls | approve architecture、require changes、accept technical exception | 42010 view pack、C4、data flow、tool action view |
| Model Risk Review | model fitness、limitations、monitoring | approve model use、restrict use、require validation | model card、eval report、monitoring plan |
| Security and Privacy Review | data boundary、access、vendor、logging | approve design、block data use、require controls | threat model、DPIA、access matrix |
| Operations Readiness Review | runbook、staffing、support、fallback | approve pilot readiness、hold rollout | capacity model、SOP、training、support script |
| Customer Harm / Conduct Review | fairness、disclosure、recourse、complaints | approve customer-facing use、require recourse changes | harm assessment、segment eval、communication pack |
| Release Certification Forum | readiness、residual risk、exceptions | full release、limited pilot、hold、rollback | evidence binder、decision log、open defects |
| Post-Release Learning Review | monitoring、complaints、override、adoption | scale、tune、pause、remediate | dashboard、incident、feedback、eval expansion |
Forum outcome should be a decision record, not meeting notes. Minimum fields are issue id、trigger、affected decision、stakeholders、concerns、options、evidence links、decision owner、decision、expiry or review date and monitoring signal.
7. Communication Artifacts and Evidence Binder
Communication is not a slide deck. It is an artifact system that keeps stakeholder narratives consistent and evidence-backed.
| Artifact | Purpose | Contents |
|---|---|---|
| Coalition map | understand decision dependencies | stakeholders、decision rights、hidden veto、influence signals |
| Concern matrix | turn concerns into requirements and controls | stakeholder、concern、architecture response、evidence |
| One-page decision brief | decide without re-litigating discovery | ask、options、risks、evidence、recommendation |
| Architecture view package | answer concern-specific architecture questions | C4、data、model、tool、evidence、runtime views |
| Risk appetite memo | translate risk language into thresholds | appetite interpretation、controls、gates |
| Customer communication pack | control customer-facing explanations | approved language、disclosures、recourse、FAQ |
| Evidence binder | prove decisions and readiness | source index、eval、approvals、controls、monitoring |
Every communication artifact must answer what decision it supports, which concern it addresses, which evidence it cites, and what the stakeholder must do next.
Stakeholder alignment becomes durable when evidence is organized from the start.
| Evidence class | Contents | Owner |
|---|---|---|
| Stakeholder inventory | roles、decision rights、concern inventory、hidden veto register | delivery governance |
| Decision log | decision、forum、options、rationale、owner、date、conditions | PMO / Release Manager |
| Architecture views | stakeholder impact、data flow、model/RAG/tool、controls、runtime、monitoring | architecture owner |
| Requirements traceability | concern -> requirement -> control -> evidence -> release gate | analysis owner |
| Risk and harm evidence | risk assessment、customer harm model、segment analysis、recourse design | Risk / Compliance |
| Eval and test evidence | eval contract、test pack、segment results、critical failures、acceptance criteria | QA / EvalOps |
| Security/privacy evidence | threat model、access review、data minimization、vendor review | CISO / Privacy |
| Operations evidence | runbook、SOP、training、capacity、support scripts、fallback | Operations |
| Exception evidence | residual risk、compensating control、owner、expiry、monitoring | Risk Owner |
Reference architecture:
Stakeholder and decision intelligence layer
stakeholder ontology | decision rights | concern matrix | coalition graph
|
v
Architecture viewpoint layer
impact view | decision view | data/model/tool view | control view | adoption view
|
v
Requirements and control layer
concern-derived requirements | acceptance criteria | policy controls | runtime controls
|
v
Evidence and forum layer
evals | reviews | logs | approvals | exceptions | release certification
|
v
Monitoring and learning layer
adoption | override | complaint | incident | drift | control performance
8. 为什么有效, 以及哪里会被误用
这套方法有效, 是因为它把模糊的人际阻力转换成明确的交付依赖。 Stakeholder ontology 避免 sponsor-only alignment; decision-rights map 说明谁能改变 gate 结果; concern-to-viewpoint mapping 让不同关切进入不同架构视图; traceability 让 concern 进入 requirement、control、test、evidence 和 monitoring; coalition graph 识别 formal authority、informal influence、evidence dependency 和 incentive conflict; risk narrative 把客户伤害、合规、模型、安全和运营问题放进同一条决策叙事; forum architecture 让冲突进入有 mandate 的 forum; evidence binder 让 alignment 在人员变化、审计抽样、监管质询和上线后复盘中仍可重构。
成熟 alignment 的结果不一定是全面批准。 它可能是 limited pilot、scope restriction、manual fallback、exception expiry、risk owner assignment 或 stop decision。 只要决策有证据、有 owner、有条件、有监控, coalition architecture 就在发挥作用。
| Anti-pattern | 风险 | 替代做法 |
|---|---|---|
| Sponsor-only alignment | 忽视 blocker、operator、auditor 和 harmed party | decision-rights map and concern matrix |
| Treat influence as gossip | 讨论人际关系而不处理证据和权力 | coalition graph as delivery dependency |
| Late risk engagement | release 前才发现模型、法律或安全问题 | risk and control concerns in discovery |
| One-size-fits-all architecture diagram | 不同 stakeholder concern 无法被回答 | 42010-style viewpoint package |
| Hidden veto discovery in release week | 数据、法务、运营或供应商审查晚期阻断 | hidden veto register and early review |
| Harmed parties represented only by metrics | 客户伤害、申诉和解释路径缺失 | customer harm model and recourse design |
| Risk appetite treated as slogan | 控制阈值和 escalation 不明确 | risk appetite interpretation memo |
Stakeholder architecture 不能替代真实授权。 如果组织没有明确 forum、没有 risk appetite、没有可用证据、没有运营 capacity, 再漂亮的 map 也只是形式。 它也不能用来包装绕过治理的行动; 相反, 它会暴露缺口。
9. Financial Retail System Cases
| Use case | Stakeholder concern | Architecture response |
|---|---|---|
| AI agent tools for customer support | CISO worries agent can access or update sensitive customer data; Legal worries unauthorized commitments; Support Ops worries over-trust; customers need accurate explanation and recourse. | tool gateway、action tiering、scoped auth、approved language、citation、human review、override reason、source-backed response、complaint path |
| KYC AI | Sales wants conversion; KYC Ops worries manual review load; Model Risk worries segment failure; Legal worries wrong rejection; customers may be delayed or rejected. | staged pilot、capacity model、reviewer workbench、segment eval、no final rejection by AI、recourse path、status transparency |
| AML alert triage | AML owner needs high-risk recall; analysts worry summaries omit facts; Compliance keeps SAR boundary human-controlled; Audit needs reconstructable record. | recall-focused eval、high-risk override、citation-required summary、source trace、prohibited action rule、evidence binder、action log |
| Collections hardship | Legal worries unauthorized relief promise; vulnerable customer advocate worries rigid automation; Operations worries queue increase; Compliance needs retained records. | approved language、policy citation、commitment gate、vulnerability flags、human escalation、routing design、retention map |
| Personalized pricing | Product and Sales want revenue lift; risk and compliance worry fairness, suitability and conduct risk; customers may face opaque pricing. | value hypothesis、segment fairness eval、policy constraints、offer approval、approved communication、recourse、complaint monitoring |
These cases show why stakeholder coalition is architecture. The most important decision dependency may be a data owner, a complaint process owner, a reviewer queue, a legal communication rule, or a harmed customer segment that is not present in project ceremonies.
Customer support tools require action tiers; KYC AI requires separate decision rights for extraction, recommendation and adverse action; AML triage requires recall-oriented eval and reconstructable evidence; collections hardship requires recourse; personalized pricing requires segment impact and policy constraints.
10. 学习验证
学习验证的目标是证明你能把复杂 stakeholder environment 设计成可执行的 decision coalition, 而不是写一份沟通清单。
选择 AI agent customer support、KYC AI、AML triage、collections hardship 或 personalized pricing, 产出一个 governance architecture pack。
| Artifact | Completion standard |
|---|---|
| Stakeholder ontology | 至少列出 12 个角色或团队, 标注 decision owner、influencer、reviewer、operator、blocker、harmed party 和 evidence owner。 |
| Decision-rights map | 覆盖 discovery、pilot、release、scale、rollback 五类决策, 写清 owner、forum、entry evidence 和 exit decision。 |
| Stakeholder-concern matrix | 至少 15 条 concern, 每条连接 architecture response、requirement/control 和 evidence。 |
| Concern-to-viewpoint map | 为 business、security、model risk、legal、operations、customer harm、audit 各设计一个 viewpoint。 |
| Coalition graph | 用节点和边表达 formal authority、informal influence、hidden veto、operator burden、harmed party 和 evidence dependency。 |
| Risk appetite interpretation memo | 选择三条 enterprise risk appetite phrase, 转成 AI controls、thresholds、escalation triggers 和 residual risk owner。 |
| Forum architecture | 定义每个 forum 的 mandate、membership、entry evidence、possible outcomes 和 decision record。 |
| Evidence binder index | 列出 release 前必须具备的 evidence classes、owner、version、retention 和 monitoring signal。 |
自检标准: decision clarity、architecture translation、financial retail realism、influence risk maturity、risk narrative、evidence discipline 和 adoption realism 都必须可见。 核心记忆: AI alignment architecture 是把 authority、concern、incentive 和 harm 转成 explicit decision rights、architecture viewpoints、requirements、controls、forums and evidence。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。