AI 底层逻辑 / 经典论文
AI Stakeholder Decision Coalition：影响力风险与对齐架构
重要说明: 本文是学习、作品集和内部架构训练材料, 不构成法律意见、监管解释、审计意见、模型验证结论、风险接受决定、组织政治建议或正式治理授权。正式项目中的决策权、审批权、职责边界、风险偏好、客户影响判断、记录保留、合规要求、劳动关系、第三方责任和上线批准必须由机构授权角色结合司法辖区、产品、客户群、内部政策和监管关系确认。访问日期按 2026-06-30 记录。
735 行ai-foundations/papers/153-ai-stakeholder-decision-coalition-influence-risk-architecture.md
AI Stakeholder Decision Coalition / Influence Risk / Alignment Architecture 解读
面向对象: Senior AI PM / AI Architect / Enterprise Architect / CBAP+ BA / Product Strategy Lead / Model Risk Partner / Operational Risk Partner / Financial Retail Transformation Lead。 核心问题: AI 项目失败经常不是因为模型不够强, 而是因为没有清楚回答谁能批准、阻断、出资、运营、审计、采用或被伤害。高级 AI PM、架构师和 BA 要把 stakeholder concern 转成 architecture viewpoints、requirements、controls、evidence、communication artifacts 和 decision forums。 学习目标: 建立 stakeholder ontology、decision-rights map、concern-to-viewpoint mapping、coalition graph、influence/risk signals、escalation path、forum architecture、evidence binder 和 adoption communication 的系统心智模型。
重要说明: 本文是学习、作品集和内部架构训练材料, 不构成法律意见、监管解释、审计意见、模型验证结论、风险接受决定、组织政治建议或正式治理授权。正式项目中的决策权、审批权、职责边界、风险偏好、客户影响判断、记录保留、合规要求、劳动关系、第三方责任和上线批准必须由机构授权角色结合司法辖区、产品、客户群、内部政策和监管关系确认。访问日期按 2026-06-30 记录。
Source Anchors
| Source | Official link | 本文使用方式 |
|---|---|---|
| ISO/IEC/IEEE 42010 Architecture Description | https://www.iso.org/standard/74393.html | 用 stakeholder、concern、architecture viewpoint、architecture view、correspondence 和 rationale 组织 AI stakeholder concern 到架构视图的映射。 |
| ISO/IEC/IEEE 29148 Requirements Engineering | https://www.iso.org/standard/72089.html | 用 stakeholder need、requirements lifecycle、information item、quality 和 traceability 组织 concern 到 requirement / control / evidence 的链路。 |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI 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 和 improvement 组织 decision forums 与 evidence discipline。 |
一句话:
Stakeholder alignment is not soft politics. It is delivery architecture: decision rights, concerns, controls, evidence and forums must be designed as deliberately as model, data, RAG and tool architecture.
1. Executive Summary
AI 项目中的 stakeholder work 经常被低估为沟通、汇报或"争取支持"。这在金融零售 AI 中不够, 因为 AI initiative 往往同时触达:
- 客户权益、资金、身份、信用、收费、拒绝、催收、投诉和救济。
- 员工工作流、授权边界、绩效压力、复核责任和 adoption resistance。
- 模型风险、信息安全、隐私、法务、合规、内审、供应商和第三方风险。
- 产品收入、运营成本、销售激励、风险偏好、客户体验和品牌信任。
成熟做法不是把 stakeholder 当成通讯录, 而是建立一套 decision coalition architecture:
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
高级 PM / BA / Architect 的核心能力:
| Capability | 成熟表达 |
|---|---|
| Identify who matters | 不只列 sponsor, 还识别 approver、blocker、funder、operator、reviewer、auditor、adopter、harmed party 和 hidden veto。 |
| Translate concerns | 把 CISO、CRO、Legal、Model Risk、Product、Sales、Ops、Support 和 customer concerns 转成 viewpoint、requirement、control 和 evidence。 |
| Align incentives | 看清 misaligned incentives: 销售要转化、风险要保守、运营要容量、客服要解释、合规要证据、产品要速度。 |
| Govern decisions | 把 launch / pilot / exception / stop / scale 变成有 forum、有 quorum、有证据、有记录的 decision architecture。 |
| Manage influence risk | 不把影响力风险当 gossip, 而是用 decision rights、risk appetite interpretation、narrative conflict 和 evidence gap 管理交付风险。 |
2. Thesis: Coalition Alignment Is Architecture
低成熟度说法:
我们需要 stakeholder buy-in。
我们要多沟通。
这个团队不支持, 所以项目慢。
高级架构说法:
Which decisions are required?
Who has authority to 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 decide conflicts and exceptions?
What signals show hidden veto or adoption resistance before delivery is blocked?
AI stakeholder alignment 的本质不是让所有人同意, 而是让不同 concern 被可验证地处理:
| 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
Stakeholder 不是一个角色标签, 而是与 AI initiative 的决策、责任、影响和证据关系。
| 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 | 哪个未显性约束会晚期爆发? |
高级 stakeholder mapping 要区分:
decision owner != influencer != reviewer != operator != harmed party
例如, KYC AI 的 Product Owner 可以定义业务目标, Model Risk 可以阻断模型上线, Operations 需要运行人工复核队列, Legal 需要控制客户沟通, CISO 需要控制数据和工具边界, 新客和弱势客户是潜在 harmed parties。把这些混成"stakeholder: risk/legal/ops"会导致真正的 decision architecture 不清楚。
4. Decision-Rights Map
AI initiative 至少要映射七类权力:
| Decision right | 需要谁 | 决策对象 | Evidence required |
|---|---|---|---|
| Approve | Sponsor、Business Owner、Risk Owner、Architecture Board | 是否进入 discovery、pilot、release、scale | business case、risk tier、architecture pack、eval result |
| Block | CISO、Legal、Compliance、Model Risk、Operations、Records | 哪些条件不满足时不能继续 | blocker criteria、open gaps、risk memo |
| Fund | Portfolio Council、Finance、Platform Owner | 预算、平台 capacity、SME time | value case、cost-to-serve、delivery roadmap |
| Operate | Ops Owner、Support Owner、SRE、Vendor Manager | 谁运行流程、监控、fallback 和 incident response | runbook、training、capacity model、SLO |
| Audit / assure | Internal Audit、Control Testing、Model Validation | 是否能独立检验证据和控制 | evidence binder、decision log、control matrix |
| Adopt | Frontline manager、team lead、customer segment owner | 谁真正使用、推荐或接受系统 | adoption plan、training、feedback、override metrics |
| Be protected | Customer advocate、Compliance、Accessibility, complaint owner | 如何避免、发现和补救 harm | harm model、recourse journey、monitoring and remediation |
Decision-rights map 的最低结构:
| Decision | Owner | Influencers | Reviewers | Operators | Harmed parties | Forum | Entry evidence | Exit decision |
|---|---|---|---|---|---|---|---|---|
| Move KYC AI to pilot | Retail Onboarding Owner | Sales, Ops, Data Science | 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 | Support Director, Platform | 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 | Analyst leads, CRO delegate | Model Risk, Compliance, Audit | AML operations | Bank, customers, regulators | Financial Crime AI Committee | recall eval, override analysis, SAR boundary | scale / restrict / retrain |
错误做法是只画 RACI。RACI 经常回答"谁参与工作", 但不回答"谁能改变决策"。
5. Stakeholder-Concern Matrix
Stakeholder-concern matrix 是把 influence risk 转成可管理需求的核心工具。
| Stakeholder | Primary concerns | Risk if ignored | Architecture response | Evidence |
|---|---|---|---|---|
| CISO | 数据边界、供应商、tool action、secrets、logging | late security block, production access denial | trust boundary view、tool gateway、redaction、security control view | threat model、access review、action ledger test |
| CRO / Operational Risk | 客户伤害、控制失败、risk appetite、residual risk | risk exception rejected, release hold | harm model、risk-control matrix、exception process | risk memo、control test、monitoring threshold |
| Legal / Compliance | 客户承诺、合规义务、records、disclosure、fairness | legal veto, communication rewrite, regulator issue | approved language view、record retention、policy constraint map | legal review record、communication pack、retention map |
| Model Risk | model fitness, validation, monitoring, limitation | model approval delay or prohibition | eval contract、model/prompt/RAG version view、human review design | validation pack、eval report、drift monitoring |
| Product | value, adoption, journey, speed, differentiation | project loses funding or scope | outcome map、journey view、feature and KPI architecture | benefit baseline、adoption metrics |
| Sales | conversion, incentive, customer conversation, friction | passive resistance, workaround | sales narrative, guardrailed recommendation flow | sales enablement pack、override analysis |
| Operations | workload, queue, SOP, escalation, staffing | launch fails despite technical pass | operating model view、capacity model、fallback runbook | training record、queue simulation、readiness signoff |
| Customer support | explanation, complaint handling, agent trust | increased calls and inconsistent answers | support script, evidence retrieval, complaint workflow | support FAQ、case evidence view、complaint dashboard |
| Customers | clarity, fairness, recourse, privacy, service continuity | harm, complaints, loss of trust | customer journey, recourse path, disclosure, human escalation | segment eval、recourse test、monitoring |
| Internal Audit | decision trail, evidence completeness, control operation | audit finding after launch | evidence binder architecture、decision log | evidence index、sample traces、approval ledger |
Matrix rule:
Every material stakeholder concern must map to at least one architecture view,
one requirement or control,
and one evidence artifact.
If a concern only maps to "we will communicate", the architecture is incomplete.
6. Concern-to-Viewpoint Mapping
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 stakeholder concerns? | Requirements traceability view | concern -> need -> requirement -> acceptance criterion | backlog and scope baseline |
| What controls answer those 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 |
| What narrative conflicts exist? | Communication architecture view | value story, risk story, customer story, operator story | steering, communication, expectation setting |
Viewpoint design questions:
- Which stakeholder concern is this view answering?
- What decision cannot be made without this view?
- Which evidence must accompany the view?
- Which stakeholder can challenge the view?
- What changes would invalidate the view?
7. Traceability: Concern to Requirement, Control and Evidence
ISO 29148-style requirements thinking becomes powerful when stakeholder concerns are not left as meeting notes.
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 | The agent orchestration service must route profile write actions through a tool gateway that enforces 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 or agent-facing hardship language must stay inside approved policy and preserve escalation rights. |
| Requirement | The assistant must cite active hardship policy, avoid final commitment language unless authorized, and route policy uncertainty to a trained 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. |
Traceability rule:
If a stakeholder concern cannot be traced to requirement, control and evidence,
it is still an unresolved delivery risk.
8. Coalition Graph
A coalition graph shows how decision influence moves through people, committees, systems, evidence and incentives.
AI initiative
-> decisions required
-> formal forums
-> formal decision owners
-> informal influencers
-> blockers and hidden vetoes
-> operators and adopters
-> harmed parties and advocates
-> evidence dependencies
Minimum graph nodes:
| 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, HITL, access control, monitoring threshold, recourse process |
| Signal | veto risk, narrative conflict, adoption resistance, evidence gap |
Edges should be explicit:
| Edge | Meaning |
|---|---|
| owns_decision | actor has final decision right |
| can_block | actor or forum can stop progression |
| influences | actor shapes opinion or adoption |
| operates | actor runs the process after release |
| is_harmed_by | segment may be negatively affected |
| requires_evidence | decision needs artifact |
| satisfies_concern | artifact/control answers concern |
| conflicts_with | stakeholder concern or incentive conflicts with another |
Coalition graph example for personalized pricing:
Product owns revenue target
Sales influences adoption and customer explanation
CRO can block risk appetite breach
Legal can block unfair or unclear pricing communication
Model Risk reviews model fitness and monitoring
Operations owns exception handling
Support handles customer complaints
Customers can be harmed through unfair, opaque or inconsistent offers
Audit requires traceability from pricing rule to offer evidence
This graph is not gossip. It is a decision dependency map.
9. Influence and Risk Signals
Influence risk is delivery risk created by unclear authority, conflicting incentives, weak evidence or late-stage concern discovery.
| Signal | What it means | PM / BA / Architect 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 with audience-specific views |
| 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 |
| Sales asks for "more flexible" AI recommendations | incentive conflict with control boundary | separate recommendation, commitment and decision authority |
| 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 |
| Support sees rising complaints in pilot | customer harm or expectation mismatch | pause scale, analyze complaint taxonomy, adjust disclosure and recourse |
| Sponsor pushes release despite evidence gaps | governance pressure | move decision to formal forum with exception record and risk owner |
Severity scoring:
| Factor | Low | Medium | High |
|---|---|---|---|
| Decision authority | concern from participant | concern from reviewer | concern from formal blocker |
| Customer impact | internal productivity | employee-assisted decision | customer money, access, eligibility, legal rights |
| Evidence gap | artifact exists but unclear | partial evidence | no evidence or contradictory evidence |
| Timing | discovery | build | release or scale gate |
| Incentive conflict | aligned but cautious | local KPI conflict | compensation, liability or regulatory conflict |
| Recoverability | easy to rework | rollout delay | stop, rollback, customer remediation |
10. Hidden Veto and Misaligned Incentives
Hidden veto appears when a team can block progress without being visible in the official decision map.
Common hidden veto sources:
| 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 |
| Complaint owner | rejects support script | complaint journey and support evidence view |
| Finance | questions benefit case | baseline, unit economics and value evidence |
| Sales leadership | fears revenue friction | incentive and narrative workshop |
Misaligned incentives are not character flaws. They are architecture inputs.
| 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 |
11. Risk Appetite Interpretation
Risk appetite statements often live at enterprise level. AI teams must translate them into operational design.
| 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 interpretation memo should include:
- AI use case and affected population.
- Customer, financial, legal, operational, model and security risk categories.
- Risk appetite phrases from policy or leadership.
- Operational translation into thresholds, controls and escalation.
- Evidence required before pilot, release and scale.
- Residual risk owner and exception process.
12. Narrative Conflict
AI initiatives often carry multiple narratives:
| Narrative | Who may hold it | Risk |
|---|---|---|
| "This is a productivity tool" | Product, transformation, finance | underestimates customer and control impact |
| "This is a model risk initiative" | Model Risk, AI governance | over-focuses on model metrics, misses workflow adoption |
| "This is a security exposure" | CISO, data owner | blocks useful tool action without tiering |
| "This will replace jobs" | Operators, frontline staff | adoption resistance and workarounds |
| "This will improve customer fairness" | Customer advocate, compliance | needs segment evidence, not intent |
| "This will improve sales conversion" | Sales, product | may conflict with suitability, fairness or disclosure |
Narrative conflict is resolved through architecture views, not slogans.
| Conflict | View needed | Evidence |
|---|---|---|
| Productivity vs control | human accountability view | before/after workflow, HITL coverage, quality samples |
| Revenue vs fairness | pricing policy and segment view | fairness eval, offer distribution, complaint monitoring |
| Autonomy vs safety | tool action view | action tier, dry-run, approval, rollback |
| Speed vs validation | staged release view | pilot gate, exposure cap, eval threshold |
| Efficiency vs employment fear | operating model view | role redesign, training, adoption metrics |
13. Escalation Paths
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 |
Escalation record minimum fields:
issue_id
trigger
affected decision
stakeholders
concerns
options
recommended path
evidence links
decision owner
decision
expiry or review date
monitoring signal
14. Forum Architecture
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 design rules:
- Each forum has decision scope, membership, quorum, entry evidence and possible outcomes.
- Forum outcomes are decision records, not meeting summaries.
- No forum should approve what it cannot understand or monitor.
- High-impact AI needs a path from working-level challenge to executive risk decision.
15. Communication Artifacts
Communication is not a slide deck. It is an artifact system that keeps stakeholder narratives consistent and evidence-backed.
| Artifact | Audience | Purpose | Contents |
|---|---|---|---|
| Coalition map | PM, sponsor, delivery lead | understand decision dependencies | stakeholders, decision rights, hidden veto, influence signals |
| Concern matrix | PM, BA, architect, risk | turn concerns into requirements and controls | stakeholder, concern, architecture response, evidence |
| One-page decision brief | steering committee | decide without re-litigating discovery | ask, options, risks, evidence, recommendation |
| Architecture view package | architects, security, risk | answer concern-specific architecture questions | C4, data, model, tool, evidence, runtime views |
| Risk appetite memo | risk, sponsor, legal | translate risk language into thresholds | appetite interpretation, controls, gates |
| Operator adoption pack | operations, support, frontline managers | prepare users and supervisors | workflow change, SOP, training, escalation, metrics |
| Customer communication pack | legal, compliance, support | control customer-facing explanations | approved language, disclosures, recourse, FAQ |
| Evidence binder | audit, governance, release forum | prove decisions and readiness | source index, eval, approvals, controls, monitoring |
Quality standard:
Every communication artifact must answer:
what decision it supports,
which concern it addresses,
which evidence it cites,
and what the stakeholder must do next.
16. Evidence Binder
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 | PM / BA |
| Decision log | decision, forum, options, rationale, owner, date, conditions | PMO / Release Manager |
| Architecture views | stakeholder impact, data flow, model/RAG/tool, controls, runtime, monitoring | Architect |
| Requirements traceability | concern -> requirement -> control -> evidence -> release gate | Senior BA |
| 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 |
| Communication evidence | approved language, stakeholder brief, customer FAQ, support guidance | Product / Legal |
| Monitoring evidence | dashboards, thresholds, alerts, complaint signals, adoption metrics | Platform / Ops |
| Exception evidence | residual risk, compensating control, owner, expiry, monitoring | Risk Owner |
Evidence binder should answer:
- Who decided this AI capability was acceptable?
- Which stakeholder concerns were considered?
- Which requirements and controls were derived from those concerns?
- Which evidence proves the controls and requirements?
- Which residual risks were accepted by whom?
- How will the team detect harm, drift, misuse or adoption failure?
17. Financial Retail Examples
17.1 AI Agent Tools for Customer Support
| Stakeholder | Concern | Architecture response |
|---|---|---|
| CISO | agent can access or update sensitive customer data | tool gateway, action tiering, scoped auth, action ledger |
| Legal / Compliance | agent may create unauthorized customer commitments | approved language, citation, human review for commitments |
| Support Ops | agents may over-trust AI or slow down | confidence display, training, override reason, supervisor dashboard |
| Product | wants lower AHT and better resolution | benefit baseline, journey metrics, quality guardrails |
| Customer | wants accurate explanation and recourse | source-backed response, handoff, complaint path |
17.2 KYC AI
| Stakeholder | Concern | Architecture response |
|---|---|---|
| Sales | onboarding friction reduces conversion | staged pilot, explainable review, queue SLA |
| KYC Ops | AI creates more manual review | capacity model, triage categories, reviewer workbench |
| Model Risk | document extraction and pass/review recommendation may fail by segment | eval by document type, channel, language, quality and fraud patterns |
| Legal / Compliance | wrong rejection or insufficient notice | no final rejection by AI, recourse path, approved notice |
| Customer | may be wrongly delayed or rejected | customer harm model, status transparency, appeal |
17.3 AML Alert Triage
| Stakeholder | Concern | Architecture response |
|---|---|---|
| AML Program Owner | AI must not miss high-risk alerts | recall-focused eval, high-risk override, analyst review |
| Analysts | AI summaries may omit material facts | citation-required summary, source trace, feedback loop |
| Compliance | SAR boundary must remain human-controlled | prohibited action rule, decision authority view |
| Audit | investigation record must be reconstructable | evidence binder, action log, model/prompt version |
| CRO | financial crime risk appetite | risk appetite memo, monitoring thresholds |
17.4 Collections Hardship
| Stakeholder | Concern | Architecture response |
|---|---|---|
| Legal | AI may promise relief or waive obligations incorrectly | approved language, policy citation, commitment gate |
| Customer support | agents need empathetic but compliant scripts | response library, escalation to hardship specialist |
| Vulnerable customer advocate | customers in hardship may be harmed by rigid automation | vulnerability flags, human escalation, recourse |
| Operations | case queue may increase | routing design, staffing model, SLA monitor |
| Compliance | records and customer communication must be retained | retention map, call/case evidence, audit trail |
17.5 Personalized Pricing
| Stakeholder | Concern | Architecture response |
|---|---|---|
| Product / Sales | wants tailored offers and revenue lift | value hypothesis, offer strategy, adoption plan |
| CRO / Compliance | fairness, suitability, risk appetite and conduct risk | segment fairness eval, policy constraints, offer approval |
| Legal | disclosure and customer understanding | approved communication, explainability boundaries |
| Model Risk | pricing model limitations and monitoring | model card, eval, drift and override tracking |
| Customers | may face opaque or unfair pricing | recourse, explanation, complaint monitoring |
18. 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
Core objects:
| Object | Minimum fields |
|---|---|
| Stakeholder | role, decision rights, concerns, incentives, influence, evidence needs |
| Concern | source, category, severity, affected party, architecture response, owner |
| Decision | decision type, forum, owner, options, entry evidence, outcome |
| Viewpoint | stakeholder, concern, model kind, required evidence, update trigger |
| Requirement | statement, source concern, owner, acceptance criteria, control link |
| Control | objective, mechanism, owner, frequency, evidence, monitoring |
| Evidence | artifact id, version, source, integrity, approver, retention |
| Signal | adoption, override, complaint, defect, veto risk, narrative conflict |
19. PM / BA / Architect Implications
| Role | 高级贡献 |
|---|---|
| Senior AI PM | 把 stakeholder alignment 转成 value, adoption, funding, release and scale decisions, 不把沟通当附属任务。 |
| CBAP+ BA | 把 stakeholder concern 转成 stakeholder need、requirement、acceptance criteria、control 和 traceability。 |
| AI Architect | 为不同 concern 设计 viewpoints: data, model, RAG, tool, control, evidence, runtime, adoption。 |
| Enterprise Architect | 把 decision forums、AI management system、portfolio governance 和 architecture board 连接起来。 |
| Risk / Compliance Partner | 把 risk appetite、customer harm、policy constraint 和 evidence standard 前置到设计。 |
| Operations Lead | 把 adoption、workflow burden、queue capacity、training、fallback 和 support evidence 纳入 release gate。 |
高级表达:
I do not manage stakeholders as a communication list. I model stakeholders as decision-rights, concerns, incentives, controls and evidence dependencies, then design the architecture views and forums required to resolve them.
20. Anti-Patterns
| Anti-pattern | 风险 | 替代做法 |
|---|---|---|
| Sponsor-only alignment | 忽视 blocker、operator、auditor 和 harmed party | decision-rights map and concern matrix |
| RACI without decision rights | 参与者多但真正批准权不明 | decision owner / influencer / reviewer / operator split |
| 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 |
| Communication without evidence | 用 storytelling 替代 readiness | evidence-cited decision briefs |
| Hidden veto discovery in release week | 数据、法务、运营或供应商审查晚期阻断 | hidden veto register and early review |
| Operators ignored | 系统上线但没人愿意用或不会用 | operating model and adoption evidence |
| Harmed parties represented only by metrics | 客户伤害、申诉和解释路径缺失 | customer harm model and recourse design |
| Risk appetite treated as slogan | 控制阈值和 escalation 不明确 | risk appetite interpretation memo |
21. Interview Answers
Q1: 你如何管理 AI 项目的复杂 stakeholder?
30 秒版本:
我不会只做 stakeholder list。我会建立 decision-rights map, 区分 decision owner、influencer、reviewer、operator、blocker 和 harmed party。然后把每类 stakeholder concern 转成 architecture viewpoint、requirement、control 和 evidence, 放进明确的 decision forums。这样 alignment 不是靠说服, 而是靠清楚的权力、证据和决策路径。
2 分钟版本:
金融零售 AI 项目通常涉及 CISO、CRO、Legal、Compliance、Model Risk、Product、Sales、Operations、Support、Audit 和客户。每个人关心的不是同一件事。比如客服 AI agent, Product 关心 AHT 和采用率, CISO 关心 tool action 和数据边界, Legal 关心客户承诺, Ops 关心队列和培训, 客户关心准确解释和救济。
我的做法是先建立 stakeholder ontology 和 decision-rights map: 谁能批准, 谁能阻断, 谁出资, 谁运营, 谁审计, 谁采用, 谁可能受伤害。接着建立 concern matrix, 把每个 concern 映射到 architecture view, requirement, control and evidence。最后用 forum architecture 管理冲突: architecture review 解决系统边界, model risk review 解决模型适用性, operations readiness 解决运行准备, release certification 决定 pilot / scale / hold。这样影响力风险被转成 delivery architecture。
Q2: 什么是 hidden veto, 如何提前发现?
30 秒版本:
Hidden veto 是没有出现在正式 RACI 中, 但可以在晚期阻断项目的角色或约束, 比如 data owner、records、legal hold、vendor risk、channel operations 或 accessibility review。我会通过 decision-rights map、source inventory、forum entry criteria 和 concern matrix 在 discovery 阶段暴露它。
2 分钟版本:
例如 KYC AI 项目, 团队以为 Product 和 Model Risk 是关键决策人, 但真正晚期阻断可能来自 data owner: 客服转写或身份文档不能用于某个 AI purpose; 也可能来自 operations: 人工复核队列没有 capacity; 还可能来自 Legal: 客户拒绝通知话术不合格。提前发现的方法是问每个关键 decision: 谁能 approve, 谁能 block, 需要什么 evidence, 哪个 forum 决定, 哪个角色上线后承担运营责任。任何没有 owner 的数据、记录、沟通、运营或第三方约束都登记为 hidden veto risk。
Q3: 如何把 stakeholder concerns 转成架构需求?
30 秒版本:
我用 concern-to-requirement-control-evidence traceability。比如 CISO concern 不是写成"注意安全", 而是转成 tool gateway、action tier、approval、idempotency、action ledger 和 access review evidence。
2 分钟版本:
以 collections hardship AI 为例, Legal concern 是 AI 不能对客户做未授权承诺。我会先写 stakeholder need: hardship communication must stay within approved policy and preserve customer escalation. 然后写 requirement: assistant must cite active policy, avoid final commitment language unless authorized, and route uncertainty to specialist. 控制包括 approved response library、citation check、no-answer rule 和 human review。证据包括 policy source card、eval results for prohibited phrases、reviewer samples 和 communication approval。这样 concern 进入 backlog、architecture 和 release gate, 而不是停留在会议纪要。
Q4: 如何处理 sponsor 想快速上线, 风险团队要求更多证据的冲突?
30 秒版本:
我会把冲突转成 risk appetite and release decision problem。先明确上线范围、客户影响、残余风险、证据缺口和替代方案, 然后由正确 forum 决定 full release、limited pilot、exception release、hold 或 rollback, 并记录 owner、条件和 monitoring。
2 分钟版本:
关键不是让某一方赢, 而是让决策有证据。比如 personalized pricing AI, sponsor 想快速扩展, 但风险团队担心公平和合规。我会准备一页 decision brief: value case, affected segments, fairness eval, complaint risk, policy constraints, controls, open gaps, options. 选项可能是低风险 cohort pilot、限制自动化、增加 human review、推迟某些 segment, 或 hold。若要接受例外, 必须有 residual risk owner、expiry、compensating control 和 monitoring threshold。这样速度和风险不是情绪冲突, 而是正式决策。
22. Portfolio Exercise
选择一个金融零售 AI initiative, 例如 AI agent customer support、KYC AI、AML triage、collections hardship 或 personalized pricing, 完成以下作品集资产:
- Stakeholder ontology table: 至少列出 12 个角色, 标注 decision owner、influencer、reviewer、operator、blocker、harmed party。
- Decision-rights map: 至少列出 discovery、pilot、release、scale、rollback 五类决策, 写清 owner、forum、entry evidence 和 exit decision。
- Stakeholder-concern matrix: 至少 15 条 concern, 每条连接 architecture response 和 evidence。
- Concern-to-viewpoint map: 为 business、security、model risk、legal、operations、customer harm、audit 各设计一个 viewpoint。
- Coalition graph: 用节点和边表达 formal authority、informal influence、hidden veto 和 evidence dependency。
- Risk appetite interpretation memo: 选择三条 enterprise risk appetite phrase, 转成 AI controls、thresholds 和 escalation triggers。
- Communication artifact pack: 一页 sponsor brief、一页 risk memo、一页 operator adoption pack、一页 customer/support FAQ。
- Evidence binder index: 列出 release 前必须具备的 evidence classes, owner, version and monitoring signal。
评分标准:
| Dimension | Strong portfolio signal |
|---|---|
| Decision clarity | 能清楚解释谁能 approve、block、fund、operate、audit、adopt 或 be harmed。 |
| Architecture translation | 每个重要 concern 都进入 viewpoint、requirement、control 和 evidence。 |
| Financial retail realism | CISO、CRO、Legal、Model Risk、Product、Sales、Ops、Support 和 customer impacts 具体可见。 |
| Influence risk maturity | hidden veto、misaligned incentives、narrative conflict 和 adoption resistance 被当成交付架构管理。 |
| Evidence discipline | 决策、例外、上线和监控都有 evidence binder 支撑。 |
最终心智模型:
AI alignment architecture is the discipline of turning human authority, concern, incentive and harm into explicit architecture views, requirements, controls, forums and evidence.