AI 扩展计划 / Playbooks

AI Risk Appetite / Policy Product Management Playbook

AI Risk Appetite / Policy Product Management 的重点不是讲风险管理基础, 而是把 board / executive risk appetite 转成 AI 产品约束、risk-tiered controls、policy-as-product 生命周期、运行时 guardrails、监控指标、例外处理、证据包和产品路线图。

739 行AI_RISK_APPETITE_POLICY_PRODUCT_MANAGEMENT_PLAYBOOK.md

AI Risk Appetite / Policy Product Management Playbook

配对阅读：本手册的原理/架构解读版是 docs/ai-foundations/papers/78-ai-risk-appetite-policy-product-management.md。先读 paper 建立机制与取舍，再用本手册落地为模板、RACI 与门禁，两者不需要重复精读。

核心导读: AI Risk Appetite / Policy Product Management 的重点不是讲风险管理基础, 而是把 board / executive risk appetite 转成 AI 产品约束、risk-tiered controls、policy-as-product 生命周期、运行时 guardrails、监控指标、例外处理、证据包和产品路线图。

重要说明: 本文不是法律、合规、审计或监管意见。正式项目必须由 legal / compliance / risk / model risk / privacy / security 结合司法辖区、机构类型、客户类型、业务用途、内部政策和监管关系确认。本文的目标是训练金融零售 AI 产品治理和架构判断能力。

1. Source Anchors

这些来源作为术语和治理锚点。本文只把它们转译成产品管理语言, 不把任何框架当作单独充分的合规结论。

Anchor	Official link	本 playbook 使用方式
NIST AI Risk Management Framework	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern / Map / Measure / Manage 组织 AI 风险识别、度量、管理和治理证据。NIST 页面显示 AI RMF 1.0 正在修订, 正式项目需按访问日期复核。
ISO/IEC 42001:2023	https://www.iso.org/standard/81230.html	用 AI management system 语言把 policy、objective、risk treatment、operation、performance evaluation 和 continual improvement 连接成可运营体系。
COSO Enterprise Risk Management	https://www.coso.org/guidance-on-erm	用 ERM 与 strategy / performance 的关系理解 risk appetite: 风险偏好不是合规文件, 而是战略取舍、绩效边界和管理层决策语言。

2. Core Positioning

AI Risk Appetite / Policy Product Management 是把董事会和高管层的风险偏好转译成 AI 产品可以执行的约束系统: 哪些场景能做、做到什么自动化程度、用什么数据和工具、需要什么人工监督、达到哪些指标才能上线、什么情况下暂停、例外如何审批、证据如何留存、路线图如何按风险容量排序。

核心表达:

Risk appetite becomes product reality only when it is translated into guardrails, tiers, controls, metrics, exceptions, monitoring, and roadmap decisions.

中文表达:

风险偏好只有进入产品边界、分层门禁、运行时控制、指标阈值、例外机制、监控留证和路线图取舍, 才真正影响 AI 产品。

3. Risk Appetite 如何转成 AI 产品约束

3.1 从董事会语言到产品语言

董事会和高管层通常不会说“这个 prompt 能不能调用账户冻结工具”。他们会说:

我们愿意为效率提升承担多大的客户体验风险。
我们在信贷、财富、AML、欺诈、投诉等场景的自动化边界在哪里。
我们对客户权益、监管信任、声誉、模型错误、数据泄露和操作风险的容忍度是多少。
我们希望 AI 支持增长, 但不能突破公平性、透明度、人工复核和可审计要求。
我们愿意在哪些低风险场景快速试验, 哪些场景必须先有控制框架再扩展。

AI 产品治理的工作是把这些高层表达转成产品可执行对象:

Risk appetite language	Product constraint	具体产品化表达
对客户权益影响零容忍	Automation boundary	AI 不直接做最终拒贷、适当性判断、账户关闭、可疑活动结论或客户赔付拒绝; 只能建议、摘要、准备材料或触发人工复核。
对敏感数据外泄低容忍	Data boundary	PII、账户、收入、医疗、未成年人、身份文件等数据进入数据分级; 外部模型、日志、RAG index、训练集和导出能力都有 allowlist。
对监管解释不可接受黑箱	Explainability constraint	高风险输出必须绑定政策条款、数据来源、reason code、模型/规则版本、人工批准记录和客户可理解解释。
对操作效率有明确目标	SLO / value metric	AI 方案必须在人工复核保留的前提下降低处理时长、减少返工、提升 first-contact resolution 或增加检测覆盖。
对模型幻觉低容忍	Quality gate	客户可见答案、政策解释和财富/信贷类建议必须经过 groundedness、citation accuracy、refusal accuracy 和 red-team 门禁。
对自主 agent 行为谨慎	Tool permission	默认 read-only; 写操作、资金动作、账户状态变更、外部通知、case closure 需要工具网关、审批和幂等控制。
对创新有风险容量	Tiered experimentation	低风险内部 copilot 可快速试点; 客户影响或受监管场景走更高门禁; critical 场景先做 shadow mode 或 human-in-the-loop。

3.2 Risk Appetite Translation Loop

推荐把 risk appetite 转译做成一个固定产品管理循环:

Board / executive appetite
-> business domain appetite statement
-> AI use case tiering
-> product guardrails
-> control catalog
-> release gates
-> runtime enforcement
-> monitoring and KRIs
-> exceptions and residual risk acceptance
-> evidence binder
-> roadmap trade-offs

这个循环的关键不是一次性写文档, 而是形成可迭代机制:

Loop step	Product management question	产出
Appetite statement	组织愿意为哪些业务结果承担哪些 AI 风险, 不愿意承担哪些风险	AI risk appetite statement
Domain translation	在信贷、财富、客服、AML、欺诈、运营中边界是否不同	Domain appetite addendum
Use case tiering	这个 use case 的客户、监管、资金、数据和自动化影响是什么	Risk tier decision
Product guardrails	产品界面、workflow、API、tool、数据和披露如何限制行为	Guardrail spec
Control catalog	每个 tier 默认需要哪些控制, 哪些控制可被替代或增强	Control matrix
Release gate	上线前必须通过哪些 eval、security、privacy、risk 和 ops 检查	Go-live checklist
Runtime enforcement	控制在运行时由谁执行: 产品、policy engine、tool gateway、workflow 还是人工	PDP / PEP design
Monitoring	哪些指标说明风险偏好被接近、突破或失效	KRI / SLO dashboard
Exception	什么时候允许突破默认规则, 谁批准, 多久复核	Exception memo
Evidence	如何向 risk、audit、regulator、executive 证明控制真实运行	Evidence binder
Roadmap	风险容量不足时先做什么、延后什么、停止什么	Risk-adjusted roadmap

3.3 关键转译能力

对已有业务分析、金融零售和架构经验的人, 重点不是再补需求基础, 而是把需求对象升级为“策略产品对象”:

传统需求对象	AI policy product 对象	转译重点
Business requirement	Risk appetite constraint	需求不是只表达想做什么, 还要表达不能做什么、何时停、谁能批准例外。
Business rule	Versioned policy control	规则要有 owner、版本、测试、发布、回滚、监控和证据。
Process step	Control point	流程节点要说明是 advice、decision、approval、execution 还是 evidence capture。
Acceptance criteria	Release gate	验收标准要包括质量、风险、安全、隐私、操作可用性和可审计性。
Exception path	Risk exception product flow	例外不是邮件审批, 而是可追踪的产品流程和 residual risk 记录。
Report	Risk appetite dashboard	报告不是展示 KPI, 而是显示 appetite usage、breach、near miss、stop rule 和 roadmap 决策。

4. Risk-Tiered Product Management

4.1 分层原则

AI risk tier 不是按模型能力高低划分, 而是按业务后果划分。一个小模型如果决定信贷或账户处置, 风险可能高于一个大模型做内部文案草稿。

建议用六个维度定级:

Dimension	关键问题
Customer impact	是否影响客户权益、价格、授信、交易、账户状态、投诉、赔付、适当性或客户可见解释
Automation level	AI 是 search / summarize / recommend / decide / execute 哪一级
Data sensitivity	是否使用 PII、账户、交易、收入、身份文件、特殊类别数据、员工数据或第三方数据
Regulatory relevance	是否触发信贷、公平借贷、AML/BSA、KYC、财富建议、隐私、投诉、消费者保护、记录留存等要求
Reversibility	错误是否可快速纠正, 是否造成资金、信用、监管记录、声誉或客户信任损害
Scale and velocity	影响是单个员工、单个队列、全渠道客户还是批量自动化

4.2 Risk Tier Matrix

Tier	典型 AI 产品形态	默认控件	上线门禁	证据要求
Low	内部知识检索、文案草稿、会议摘要、非客户决策辅助	数据分类、基础日志、用户提示、approved tool list、轻量 eval	Product owner approval; security / data allowlist; sample QA	Use case card、数据边界、prompt / model version、抽样结果、用户反馈
Medium	员工 copilot、客服建议草稿、运营分类建议、政策问答辅助	RAG citation、人工确认、policy refusal、role-based access、质量监控、变更记录	Product + Risk checkpoint; eval threshold; ops readiness; monitoring dashboard	Risk tier rationale、eval report、control mapping、human review policy、incident path
High	客户可见 AI、信贷/财富/投诉/欺诈/AML 决策支持、可影响客户行动的建议	HITL、reason code、tool gateway、policy engine、red-team、independent challenge、模型/数据/工具版本控制	Cross-functional release gate; model risk / compliance / privacy review; pilot and rollback plan	Full evidence binder、validation summary、policy-to-product matrix、monitoring plan、exception log、management attestation
Critical	可能造成重大客户损害、监管承诺、资金或账户动作、自动化 adverse action、AML/欺诈结论、规模化 agent 执行	默认禁止自主执行; shadow mode; dual control; executive approval; kill switch; production watch; strict change freeze	Executive risk acceptance; board-level visibility when material; staged rollout; stop rules tested	Executive risk memo、residual risk acceptance、control test evidence、stop-rule drill、audit-ready trace、post-launch review

4.3 Tier 不是标签, 是产品工作量预算

同一个功能从 Low 到 Critical, 产品工作量会明显变化:

Product work	Low	Medium	High	Critical
Scope	单一内部任务	明确 workflow 辅助	端到端控制点	业务/风险共同定义允许范围
Discovery	用户访谈 + 样例	工作流和失败模式	客户影响和监管后果	高管风险场景和压力测试
Requirements	功能验收	质量 + 人工确认	控制 + 证据 + rollback	禁止边界 + residual risk
Design	普通 UX	引用、拒答、确认	披露、申诉、人工复核	强制人工、双控、暂停机制
Architecture	模型接入	RAG / workflow logging	policy engine / tool gateway	deterministic controls before AI
Testing	抽样 QA	eval set	independent challenge + red-team	scenario drill + executive go/no-go
Launch	小范围试点	运营试点	分阶段上线	shadow mode / limited production
Monitoring	usage / feedback	quality / override	KRI / breach / incident	real-time alerts / stop rules

4.4 Risk Tier Decision Record

每个 AI use case 应保存一条 risk tier decision record:

Field	内容
Use case name	清晰命名, 如 `Branch Banker Wealth Guidance Copilot`
Business owner	对业务结果负责的人
Product owner	对产品范围、路线图和交付证据负责的人
Risk owner	对风险分类、控制期望和 residual risk 接受路径负责的人
System boundary	模型、RAG、工具、workflow、人、渠道和外部依赖
Customer impact	影响客户权益、决策、资金、体验或解释的方式
Automation level	search / summarize / recommend / decide / execute
Data sensitivity	使用、存储、检索、外发、日志化的数据类型
Regulatory relevance	相关监管域和内部政策域
Tier rationale	为什么是 Low / Medium / High / Critical
Required controls	该 tier 的默认控制和增强控制
Release gate	上线前必须满足的条件
Review cadence	日常监控、季度复核、重大变更触发复核

5. Policy Product Lifecycle

5.1 生命周期主线

AI policy 不能只放在 PDF、Wiki 或 prompt 中。它要被产品化为可测试、可版本化、可运行、可监控、可例外、可审计的控制资产。

policy intent
-> rule / control
-> product requirement
-> runtime guardrail
-> monitoring
-> exception
-> review
-> roadmap adjustment

5.2 Policy Intent -> Rule / Control

Policy intent	Rule / control	产品问题
AI 不应提供未经授权的个性化投资建议	Advice boundary classifier + disclosure + licensed specialist handoff	如何识别 advice intent, 如何拒答, 如何升级, 如何记录
AI 不应使用未批准知识源解释信贷政策	RAG source allowlist + effective-date filter + citation requirement	哪些文档可检索, 版本如何生效, 引用缺失时怎么处理
AI 不应自主执行高风险账户操作	Tool permission + HITL + dual control	哪些 tool 是 read-only, 哪些写操作需要审批
AI 输出必须可复盘	Trace logging + evidence retention	需要记录哪些输入、版本、规则、输出和人工动作
AI 不能超过模型验证范围使用	Use-case binding + route control	如何阻止同一个 assistant 被复制到新业务场景

5.3 Rule / Control -> Product Requirement

风险控制要写进产品需求, 而不是上线前补一页合规说明:

Requirement type	示例
Functional	当客户询问“我应该买哪只基金”时, 系统识别为 personalized advice intent, 返回边界说明并引导至持牌顾问流程。
Non-functional	高风险客户可见回答的 trace retention 不低于内部记录留存要求, 并能按 case id / customer id / model version 检索。
UX	客服 agent 看到 AI 建议时必须有 accept / edit / reject / escalate 动作, 不允许一键自动发送高风险答复。
Data	RAG 只检索已批准、有效期内、权限匹配的政策文档; 过期文档不进入候选集。
Tooling	Agent 对 CRM 的写入必须通过 tool gateway, 并带有 user identity、case id、reason、approval token。
Evidence	每次 high-tier release 生成 release evidence pack, 包括 eval、red-team、control mapping、risk sign-off 和 rollback plan。

5.4 Product Requirement -> Runtime Guardrail

运行时 guardrail 要避免只靠 prompt:

Guardrail	推荐落点	说明
Identity and entitlement	IAM / relationship-based access control / access service	决定用户能看哪些客户、账户、文档和工具。
Data filtering	Retriever / feature store / data gateway	在数据进入模型前做权限、有效期、敏感性和地域过滤。
Policy decision	PDP / rules engine / DMN / OPA / Cedar	对能否回答、能否调用工具、是否需要审批做确定性判断。
Prompt instruction	Model orchestration	表达任务、风格、输出格式和安全边界, 但不作为唯一控制。
Tool enforcement	Tool gateway / PEP	对副作用动作做 allow / deny / approval / rate limit / idempotency。
Human oversight	Workflow / case management	让人工确认、修改、升级、驳回、批准和留证成为产品流程。
Disclosure	Channel UI / message composer	对客户或员工显示 AI 使用、限制、引用和下一步路径。
Monitoring	Observability / RiskOps dashboard	持续观察质量、越界、覆盖、人工覆盖率、异常和阈值突破。

5.5 Monitoring -> Exception -> Review

Policy lifecycle 的成熟度体现在例外和复核:

Signal	可能动作
Breach threshold 被触发	暂停功能、降级到人工、限制渠道、关闭工具、升级 incident
Near miss 增多	增加抽样、收紧阈值、更新 eval set、调整 prompt / RAG / policy
业务价值低于预期	缩小范围、改变 workflow insertion point、停止低价值能力
误拦截过高	调整 policy classifier、优化 UX、增加专家复核样本
人工 override 过高	分析模型质量、政策不清、培训不足或流程设计问题
新监管/内部政策变化	触发 policy review、control mapping、release gate 更新
模型或 vendor 版本变化	执行 regression eval、impact assessment、approval 或 rollback

6. Product Guardrails

6.1 Guardrail Catalog

Guardrail	产品定义	典型控件	证据
Advice boundary	AI 能提供一般信息、教育、流程说明, 还是可以给个性化建议	Intent classifier、refusal template、specialist handoff、approved language	Advice boundary test、refusal accuracy、handoff log
Automation boundary	AI 是辅助、建议、决策还是执行	Workflow state control、HITL、dual approval、autonomy cap	Automation level record、approval trace、override log
Data boundary	哪些数据可进入 prompt、RAG、模型调用、日志、训练和导出	Data classification、DLP、retrieval filter、vendor data restriction	Data inventory、access decision log、DLP alerts
Tool permission	AI agent 可以读、写、提交、通知、冻结、关闭或转账到什么程度	Tool allowlist、PDP/PEP、rate limit、idempotency、approval token	Tool call trace、deny log、approval evidence
Human oversight	哪些步骤必须人工确认、哪些需要专家、主管或 second line	Queue routing、approval workflow、sampling review、dual control	Review record、edit distance、approval SLA
Disclosure	员工或客户是否知道 AI 参与、AI 的限制和下一步路径	UI label、customer copy、citation、confidence display、handoff message	Disclosure copy version、channel screenshots、A/B outcome
Appeal / recourse	客户或员工如何质疑、申诉、纠错或要求人工处理	Escalation button、case reason、appeal queue、complaint linkage	Appeal log、resolution time、root cause
Explainability	输出如何绑定事实、政策、规则和 reason code	Citation、rule id、reason service、decision trace	Explanation sample、reason mapping、audit trace
Change control	prompt、policy、model、tool、RAG index 如何变更	Registry、approval workflow、regression eval、rollback plan	Change log、eval delta、release approval
Kill switch	风险突破时如何快速暂停或降级	Feature flag、route-to-human、tool disable、traffic cap	Exercise record、incident timeline、recovery evidence

6.2 Advice Boundary

金融零售 AI 最容易出问题的边界之一是“信息解释”和“个性化建议”的混淆。

Allowed pattern	Restricted pattern	Product guardrail
解释产品条款、费用、流程和一般风险	推荐具体投资、保险、贷款额度、债务处理方案	Intent detection + approved educational content + licensed advisor handoff
根据客户输入总结问题供人工处理	直接告诉客户“你应该申请/购买/赎回/拒绝”	Draft-only mode + human approval
提供一般预算、金融教育和术语解释	对客户个人资产、收入、风险偏好做个性化建议	Advice boundary banner + refusal + handoff
帮员工查找政策条款	替员工做最终 suitability 或 adverse action 判断	Citation required + decision remains with authorized role

产品治理要把 advice boundary 写进:

Intent taxonomy: 哪些客户话术进入 advice intent。
Response policy: 允许回答、拒答、转人工、提供教育材料的规则。
UX states: answer、cannot answer、needs specialist、needs licensed advisor。
Monitoring: 越界回答率、转人工率、误拒答率、客户投诉率。
Evidence: 测试集、红队样本、approved copy、review record。

6.3 Automation Boundary

AI 自动化边界建议使用五级:

Level	名称	说明	金融零售默认建议
L0	No AI	不使用 AI	法规或内部政策禁止的最终判断
L1	Retrieve / summarize	检索、摘要、整理证据	低中风险知识辅助
L2	Recommend / draft	给员工建议或草稿	客服、运营、投诉、AML case prep
L3	Decide with human confirmation	AI 做初判, 人工确认后生效	部分运营分流或低金额可逆动作
L4	Autonomous execute	AI 自主执行	只适合低风险、可逆、可监控、授权明确的动作

高风险金融零售场景默认不应从 L1 直接跳到 L4。路线图应清楚写出:

当前允许的最高自动化等级。
进入下一等级需要的质量、控制、运营和证据条件。
哪些边界永远不进入自主执行。
哪些动作只能在 shadow mode 中评估, 不影响客户。

6.4 Data Boundary

数据边界不是一句“遵守隐私政策”。需要把数据生命周期产品化:

Boundary point	Product decision question	控制
Collection	AI 功能是否真的需要该数据字段	Data minimization、purpose binding
Retrieval	RAG 是否只拿到用户有权访问且有效的文档	Entitlement filter、effective date、source allowlist
Prompt	哪些 PII / account data 可以进入模型上下文	Redaction、masking、field-level policy
Vendor	外部模型是否允许处理该数据, 是否保留或训练	Vendor allowlist、contractual configuration、gateway policy
Logging	日志是否记录敏感信息, 谁能查看	Secure trace store、retention、access control
Evaluation	eval set 是否含真实客户数据	Synthetic / anonymized data、controlled access
Export	员工能否导出 AI 输出或引用内容	DLP、watermark、download controls
Training	线上反馈是否可用于微调或训练	Consent / approval path、data lineage

6.5 Tool Permission

Agent 产品的风险通常从“回答错误”升级为“行动错误”。工具权限要按副作用分层:

Tool class	示例	默认权限
Read public / approved knowledge	产品 FAQ、公开利率说明、内部政策库	Low / Medium 可允许, 需 citation 和 source filter
Read customer data	账户余额、交易、KYC、投诉记录	需要身份、角色、purpose、case relationship
Draft internal update	CRM note 草稿、case summary、email draft	员工确认后写入
Write non-financial state	更新 task status、添加标签、创建工单	Medium 以上需要 approval 或 sampled review
Customer communication	发送短信、邮件、chat reply	客户影响场景需要人工确认和 approved language
Financial / account action	冻结、解冻、退款、调额、关闭账户、转账	Critical; 默认禁止自主执行, 双控和强审计
Regulatory / risk conclusion	SAR recommendation、fraud determination、adverse action reason	AI 只能准备证据和草稿, 最终由授权人员确认

6.6 Human Oversight

Human oversight 不是“旁边有个人”。它必须被设计成有权、有信息、有时间、有责任的产品流程:

Oversight failure	产品修正
人工只看到 AI 答案, 看不到证据	展示引用、规则、关键输入、置信区间和可疑点
一线人员被 KPI 推动盲目接受 AI	设计 reject / edit / escalate, 并监控 blind acceptance
审批人没有权限改变结果	审批人必须能修改、拒绝、暂停和升级
复核样本过少	按 tier、风险信号、队列、用户和模型版本做抽样
人工复核没有留证	记录 reviewer、动作、理由、时间、输入和版本

6.7 Disclosure and Appeal

客户可见 AI 场景需要把披露和申诉变成产品能力:

Capability	产品要求
AI disclosure	客户知道自己正在与 AI 或 AI-assisted 流程互动, 文案清楚但不制造恐慌。
Limitation statement	对建议边界、信息来源、非最终决策、人工帮助路径做清晰说明。
Human handoff	客户能要求人工处理, 且 handoff 带上下文, 不让客户重复叙述。
Appeal / correction	客户能质疑错误信息、补充材料、要求复查或纠正记录。
Complaint linkage	申诉、投诉、错误反馈进入同一套 case / root cause / risk monitoring。

7. Metrics

7.1 指标分层

AI risk appetite 指标要同时覆盖业务价值、风险容量、质量、运营、控制和客户结果。不要只看模型准确率。

Risk Appetite Indicators
-> KRIs
-> SLOs
-> Breach thresholds
-> Stop rules
-> Roadmap decisions

Metric layer	作用	示例
Risk Appetite Indicator	显示组织正在消耗多少风险容量	高风险 AI 覆盖客户数、自动化动作占比、客户可见 AI 占比、例外数量
KRI	显示风险是否升高	越界建议率、policy violation、hallucination、工具拒绝、投诉、near miss
SLO	显示服务和控制是否稳定	grounded answer rate、citation accuracy、human review SLA、trace completeness、rollback time
Breach threshold	明确何时视为突破风险偏好	某类越界回答超过阈值、critical tool unauthorized attempt、trace 缺失
Stop rule	明确何时暂停、降级或关闭	触发 kill switch、route-to-human、traffic cap、tool disable

7.2 Risk Appetite Indicators

Indicator	产品含义	决策用途
High-tier AI exposure	High / Critical 功能覆盖的客户、交易、case 或员工数量	判断是否需要升级 governance、审计和高管报告
Autonomous action ratio	AI 自主执行动作占全部动作比例	判断自动化是否超出批准边界
Sensitive data touchpoints	使用敏感数据的 prompt、RAG、tool、日志和 eval 数量	判断数据边界和隐私控制是否足够
Exception load	活跃例外数量、延期次数、超期例外	判断默认政策是否不合理或团队在绕开控制
Residual risk accepted	已批准 residual risk 的数量和严重度	判断风险容量是否被消耗
Customer-facing AI complaints	客户投诉、申诉、纠错与 AI 相关比例	判断客户信任和披露是否有效
Model / policy change velocity	prompt、model、index、tool、policy 变更频率	判断变更门禁和 regression eval 是否匹配速度

7.3 KRIs

KRI	适用场景	解释
Advice boundary breach rate	财富、信贷、保险、债务建议、客户服务	AI 输出越过一般信息边界进入个性化建议的比例
Unsupported answer rate	RAG、政策问答、客服	回答缺少有效引用或引用不支持结论的比例
Wrong refusal / missed refusal	客户交互、员工 copilot	应该回答却拒答, 或应该拒答却回答
Tool policy deny rate	Agent / workflow automation	工具调用被 policy engine 拒绝的比例和原因
Unauthorized tool attempt	Agent / data access	AI 或用户尝试调用未授权工具或资源
Human override rate	决策支持	人工修改、驳回或升级 AI 建议的比例
Blind acceptance rate	员工 copilot	员工未编辑直接接受 AI 输出的比例, 需要结合质量和场景判断
Complaint / appeal rate	客户可见 AI	客户对 AI 相关回答、决策或流程申诉的比例
Trace completeness	高风险场景	能否复盘输入、输出、版本、规则、审批和工具调用
Drift / policy staleness	RAG / policy-as-product	知识源过期、政策版本混用或模型行为变化

7.4 SLO

SLO	示例目标表达	说明
Citation accuracy SLO	高风险政策问答样本中, 引用支持结论的比例达到内部 release threshold	阈值由风险和业务共同定义, 不在本文给绝对数值。
Human review SLA	High-tier AI 建议在规定工作时间内完成复核	避免 AI 带来队列积压或假自动化。
Trace completeness SLO	High / Critical 场景的 trace 字段完整率达到 release gate	缺 trace 等于无法审计, 不能只看回答质量。
Policy decision latency SLO	PDP / PEP 延迟满足渠道体验要求	控制不能慢到让一线绕开。
Rollback SLO	高风险变更可在规定时间内回滚到批准版本	路线图要包含回滚演练。
Escalation reliability SLO	需要人工介入的 case 能正确进入队列并保留上下文	人工监督必须可运营。

7.5 Breach Thresholds and Stop Rules

Breach type	Stop rule	产品动作
Critical unauthorized tool execution	Immediate stop	关闭相关工具、冻结 agent 写权限、启动 incident、通知 risk / security
客户可见 advice breach 超阈值	Route-to-human	暂停客户自助回答, 改为人工或 licensed specialist handoff
Trace completeness 低于门禁	Release block	阻止上线或回滚版本, 直到日志和证据恢复
RAG 引用错误集中出现	Knowledge freeze	冻结 index 更新, 回滚知识库版本, 执行根因分析
Human override 异常升高	Traffic cap	限制流量、增加抽样、重新训练员工或调整 AI 输出
投诉或申诉集中在特定队列	Product review	暂停扩展, 做 journey / copy / policy / training 修正
Model vendor 行为变化	Regression gate	回到上一批准模型版本或进入 shadow evaluation

8. Financial Retail Case

8.1 信贷: Credit Policy Copilot

Product decision	Risk appetite translation
Positioning	AI 帮信贷人员查政策、整理材料、生成问题清单和解释草稿, 不做最终授信、拒绝或 adverse action。
Tier	High; 如果进入自动拒绝、调额或客户可见拒绝原因, 升为 Critical。
Guardrails	只检索有效期内政策; reason code 来自规则/决策服务; AI 草稿必须人工确认; 客户可见解释使用 approved language。
Metrics	Unsupported policy answer、reason mismatch、manual override、adverse action complaint、trace completeness。
Evidence binder	风险定级、policy source allowlist、eval set、信贷专家 review、fairness challenge、release approval、post-launch review。
Roadmap implication	先做 L1/L2 policy copilot, 再做 shadow recommendation, 只有证据充分时才扩大到 low-risk prefill。

8.2 财富建议: Wealth Guidance Assistant

Product decision	Risk appetite translation
Positioning	AI 提供教育、产品信息、会议准备和顾问草稿; 不直接给客户个性化买卖建议。
Tier	High for advisor-facing; Critical if customer-facing personalized advice or execution is contemplated。
Guardrails	Advice intent classifier、licensed advisor handoff、disclosure、suitability workflow separation、approved educational content。
Metrics	Advice boundary breach、handoff success、客户误解/投诉、顾问 edit rate、citation accuracy。
Evidence binder	Advice boundary policy、test suite、approved copy、advisor workflow record、training material、monitoring dashboard。
Roadmap implication	路线图从 advisor productivity 开始, 不是从 autonomous robo-advice 开始; 客户自助能力先限定为教育和流程说明。

8.3 客服: Customer Service Copilot

Product decision	Risk appetite translation
Positioning	AI 帮客服总结客户问题、检索政策、起草回复、推荐下一步; 高风险回复必须人工确认。
Tier	Medium for internal draft; High for customer-visible auto-reply or complaint handling; Critical for account actions。
Guardrails	Sensitive intent routing、complaint escalation、approved language、manual send、PII redaction、case trace。
Metrics	First-contact resolution、wrong answer、complaint escalation miss、manual edit distance、customer appeal、AI-related CSAT movement。
Evidence binder	Conversation samples、policy citation QA、human review log、complaint linkage、control mapping、rollback plan。
Roadmap implication	先提升 agent assist 和 case summarization, 再扩展到低风险自助问答; 涉及费用、争议、关闭账户时保持人工。

8.4 AML: Case Investigation Assistant

Product decision	Risk appetite translation
Positioning	AI 帮 AML 分析师整理交易、提取实体关系、总结证据、起草 narrative; 不做最终 suspicious activity conclusion。
Tier	High; 如果 AI 自动做 SAR / no-SAR 结论或提交监管报告, 属 Critical 且默认不允许自主执行。
Guardrails	Analyst-in-control、source trace、case evidence linkage、禁止自动提交、tool read restrictions、audit logging。
Metrics	Analyst override、missed escalation、unsupported narrative、case aging、quality review findings、trace completeness。
Evidence binder	Typology mapping、case sample eval、analyst QA、model / prompt / tool version、review notes、issue remediation。
Roadmap implication	AI 优先做 evidence preparation 和 workload triage; SAR 决策权、质量复核和提交权限保留给授权人员。

8.5 横向落地模式

金融零售 AI 风险偏好落地可以用同一张横向图:

Domain risk appetite
-> approved AI use cases
-> automation boundary
-> data and tool boundary
-> human oversight design
-> release gate
-> monitoring dashboard
-> exception and issue management
-> roadmap funding and sequencing

Domain	推荐先做	谨慎推进	默认高管关注
Credit	政策检索、材料完整性、员工草稿	自动 eligibility / reason code	自动拒贷、调额、adverse action
Wealth	顾问准备、教育内容、会议总结	客户自助教育问答	个性化买卖建议和自动交易
Customer service	员工 copilot、摘要、低风险 FAQ	自动回复费用、争议、投诉	自动关闭账户、拒绝赔付、投诉裁定
AML / Fraud	case summarization、证据关联、优先级建议	自动分流和低风险 closure	SAR / no-SAR、账户冻结、欺诈最终结论

9. Evidence Artifacts

9.1 AI Risk Appetite Statement

# AI Risk Appetite Statement - [Domain / Product]

## Strategic Intent
- Business outcome: [要达成的业务结果, 如降低客服处理时长、提高 AML case coverage、提升信贷政策一致性]
- AI role: [retrieve / summarize / recommend / decide / execute]
- Approved channels: [employee desktop / branch / call center / mobile app / batch operation]

## Appetite Boundaries
- Customer impact appetite: [可接受的客户影响范围和明确禁止的影响]
- Automation appetite: [当前允许的最高自动化等级]
- Data appetite: [允许使用、禁止使用、需要额外审批的数据类型]
- Tool appetite: [允许 read-only、draft、write、external communication、financial action 的边界]
- Advice / decision appetite: [允许一般信息、员工建议、客户建议、最终决策的边界]

## Required Guardrails
- Human oversight: [谁复核、何时复核、能否修改或拒绝]
- Disclosure: [员工或客户看到的 AI 使用和限制说明]
- Monitoring: [RAI / KRI / SLO]
- Stop rules: [触发暂停、降级、回滚、关工具的条件]
- Evidence: [上线前和上线后证据包清单]

## Residual Risk and Review
- Residual risk accepted by: [角色, 不是个人姓名]
- Review cadence: [月度 / 季度 / 重大变更触发]
- Expiry / renewal: [例外或风险接受的复核日期]
- Roadmap implication: [哪些能力可以做、哪些延后、哪些不做]

9.2 Policy-to-Product Matrix

Policy intent	Product requirement	Runtime control	Metric	Evidence
AI 不提供个性化投资建议	识别 advice intent 并转 licensed advisor	Intent classifier + refusal + handoff	Advice breach rate、handoff success	Test cases、approved copy、handoff log
高风险回答必须有有效来源	客户/员工看到政策引用和生效日期	RAG source allowlist + citation checker	Citation accuracy、unsupported answer	Eval report、retrieval trace
Agent 不自主执行账户动作	写操作需 approval token	Tool gateway + PEP + dual control	Unauthorized attempt、approval SLA	Tool trace、approval record
敏感数据不进入未批准模型	模型调用前做数据分类和 redaction	Model gateway + DLP	DLP alert、blocked request	Gateway log、data inventory
变更必须可回滚	prompt/model/index/tool 有版本和 regression eval	Registry + release gate + feature flag	Rollback time、eval delta	Change log、release approval

9.3 Exception Memo

# AI Policy Exception Memo - [Use Case / Control]

## Exception Summary
- Requested exception: [要偏离的默认政策或控制]
- Product / use case: [功能名称和业务域]
- Risk tier: [Low / Medium / High / Critical]
- Business reason: [为什么默认控制无法满足业务目标]
- Duration: [固定期限或触发条件, 不写无限期]

## Risk Analysis
- Appetite boundary affected: [customer impact / automation / data / tool / advice / evidence]
- Potential harm: [客户、运营、监管、声誉、财务、数据]
- Compensating controls: [替代控制, 如更高人工抽样、流量限制、只读模式、额外披露]
- Residual risk: [剩余风险如何被 owner 接受和监控]

## Approval and Conditions
- Approver roles: [business owner / risk owner / data owner / security / executive]
- Conditions: [流量上限、适用队列、额外监控、到期复核]
- Stop rules: [触发立即终止例外的条件]
- Evidence required: [运行日志、抽样复核、KRI、incident report]

## Review
- Review date: [明确日期]
- Renewal criteria: [续期必须满足的证据]
- Exit path: [如何回到标准控制或永久停止能力]

9.4 Risk Review Agenda

# AI Product Risk Review Agenda - [Date]

## 1. Appetite Usage
- High / Critical use cases live or in pilot
- Customer / employee / case exposure
- Active exceptions and residual risk accepted

## 2. New or Changed Use Cases
- New use case tiering decisions
- Domain appetite conflicts
- Required controls and release gates

## 3. Control Performance
- KRIs crossing warning threshold
- SLO misses
- Human override and blind acceptance trends
- Tool deny / unauthorized attempt trends

## 4. Incidents, Near Misses, and Complaints
- Incident timeline and root cause
- Customer complaints or appeals linked to AI
- Remediation owner and due date

## 5. Policy and Change Review
- Prompt / model / RAG / policy / tool changes
- Regression eval results
- Evidence binder completeness

## 6. Roadmap Decisions
- Features approved to scale
- Features capped, redesigned, delayed, or stopped
- Platform controls needed before next tier expansion

9.5 Evidence Binder Structure

Section	内容
Executive summary	Use case、risk tier、business outcome、risk appetite alignment、go/no-go decision
System boundary	模型、prompt、RAG、data、tools、workflow、人、渠道、vendor
Risk tiering	定级依据、客户影响、自动化等级、数据敏感性、监管相关性
Policy mapping	Policy intent、control、requirement、runtime guardrail、owner
Evaluation	Golden set、red-team、edge cases、citation、refusal、tool tests、human review
Security / privacy	Data flow、access、DLP、vendor restriction、logging、retention
Release evidence	Approval、change log、rollback plan、training、ops readiness
Monitoring	KRI、SLO、threshold、dashboard、alert routing
Exceptions	Active / expired exception、approver、conditions、residual risk
Post-launch review	Adoption、value、risk signals、incident、roadmap decision

10. Product Roadmap Connection

Risk appetite 不是只决定“能不能上线”, 还决定 roadmap 如何排序。

10.1 Risk-Adjusted Roadmap

Roadmap question	Risk appetite answer
先做哪个 use case	优先选择高价值、低不可逆损害、数据边界清晰、人工监督可运营的场景
什么时候扩大渠道	当质量、控制、投诉、人工复核和 trace evidence 持续稳定
什么时候增加自动化	当 L1/L2 有足够证据证明错误模式可控, 且 L3 的 human confirmation 可运营
什么时候接入工具	当 tool permission、approval token、idempotency、rollback、audit trace 都可用
什么时候暂停路线图	当风险容量被 breach、near miss 增多、证据不完整或例外过多
什么时候建设平台能力	当多个团队重复需要 eval、policy engine、tool gateway、RAG governance、evidence binder

10.2 Roadmap Patterns

Pattern	适用场景	风险偏好逻辑
Internal-first	财富、信贷、AML、投诉	先让员工使用 AI, 观察 override 和质量, 再考虑客户可见能力
Read-only-first	Agent / workflow automation	先只读和草稿, 再写入内部系统, 最后才考虑客户或资金动作
Shadow-before-impact	高风险决策支持	AI 在后台给建议但不影响结果, 收集对比证据
Human-in-the-loop-by-design	客户权益和监管相关	把人工复核设计成主流程, 不是临时补救
Control-platform-before-scale	多团队扩展	先建设 model gateway、policy engine、eval、observability、evidence binder
Stop-to-learn	早期事故或指标异常	暂停扩展, 把 failure taxonomy、policy、UX 和 training 修好

10.3 Roadmap Language

不成熟的路线图表达是:

我们下一季度把客服 AI 全自动化。

更成熟的说法是:

下一季度我们把客服 AI 从 internal draft 扩展到 low-risk customer self-service FAQ。
前置条件是 citation accuracy、wrong-refusal、complaint linkage、trace completeness 和 human handoff SLO 连续稳定。
费用争议、投诉、账户关闭和赔付拒绝仍保持人工确认。
如果 advice boundary breach 或 trace completeness 突破阈值, 自动降级到 agent assist。

11. Decision Narrative

11.1 Risk Appetite Must Become Product Mechanism

AI risk appetite 不能停留在董事会文件里。它必须转成四层产品机制: 第一是 use case risk tier, 判断客户影响、自动化程度、数据敏感性、监管相关性和可逆性; 第二是 product guardrails, 包括 advice boundary、automation boundary、data boundary、tool permission、human oversight、disclosure 和 appeal; 第三是 release gate 和 runtime control, 例如 policy engine、tool gateway、RAG source allowlist、HITL 和 kill switch; 第四是 metrics 和 evidence binder, 用 KRIs、SLO、breach thresholds、stop rules 和审计证据持续证明风险在偏好范围内。

11.2 Policy Product Management Loop

AI risk appetite 是 policy product management 问题, 不是纯治理文件问题。

第一步是把 board / executive appetite 翻译成产品边界: 在信贷、财富、客服、AML 这些金融零售场景里, 哪些 AI 可以检索、总结、建议, 哪些可以执行, 哪些必须永远保留人工最终判断。比如财富场景里, AI 可以做教育和顾问准备, 但不能直接给客户个性化买卖建议; AML 场景里, AI 可以整理证据和起草 narrative, 但不做最终 suspicious activity conclusion。

第二步是做 risk-tiered product management。Low-tier 内部工具可以轻量 eval 和基础日志; Medium-tier 员工 copilot 要有引用、人工确认和监控; High-tier 客户影响或受监管决策支持要有 HITL、red-team、policy engine、tool gateway、独立挑战和 evidence binder; Critical 场景默认不允许自主执行, 需要 shadow mode、双控、kill switch 和高管风险接受。

第三步是把 policy lifecycle 产品化。Policy intent 要变成 rule/control, 再变成 runtime guardrail, 进入监控、例外、复核和路线图。比如“AI 不应提供个性化投资建议”要落成 intent classifier、拒答话术、持牌顾问转接、越界率监控和 approved copy evidence。

最后用指标管理风险偏好: risk appetite indicators 看风险容量消耗, KRIs 看越界和趋势, SLO 看控制是否稳定, breach thresholds 和 stop rules 决定何时暂停、降级或回滚。这样 AI 产品既能创新, 又能把风险边界做成可执行、可监控、可审计的产品能力。

11.3 Residual Risk and Control Effectiveness

Residual risk 和 control effectiveness 是风险偏好落地的核心。AI use case inventory 按 customer impact、automation level、data sensitivity、regulatory relevance、reversibility 和 scale 定级, 再给每个 tier 绑定最低控制集。High 和 Critical 场景必须有明确 business owner、risk owner、release gate、monitoring dashboard、exception process 和 evidence binder。管理层需要看的不是模型 demo, 而是风险偏好是否被消耗、哪些例外仍然有效、哪些 KRIs 接近 breach、哪些 stop rules 被触发、管理层接受了什么 residual risk。这样 risk appetite 不只是声明, 而是进入上线、运行、暂停和路线图取舍。

11.4 Product Strategy Constraint

Risk appetite 是产品战略约束, 不是上线障碍。它帮助产品团队决定先做什么、不做什么、什么条件下扩展。比如客服 AI 不是一开始追求全自动, 而是按 internal draft、low-risk self-service、customer-visible answer、restricted workflow action 分阶段推进。每一阶段都定义 value metric、quality gate、human oversight、complaint signal 和 stop rule。这样路线图既能体现增长和效率, 又不会在信贷、财富、投诉、AML 等高风险场景把组织推到不可接受的风险位置。

11.5 Architecture Control Plane

Risk appetite 要落到架构控制面。关键是不要把政策藏在 prompt 里, 而是把 model gateway、RAG entitlement filter、policy decision point、tool gateway、workflow approval、observability 和 evidence store 设计成共享平台能力。Prompt 负责任务说明, 但授权、数据过滤、工具执行、审批和审计必须由确定性系统执行。对 High / Critical tier, 架构上要支持版本化、回归测试、traceability、kill switch、rollback、tenant / role / purpose-based access 和 policy bundle release。这样产品团队可以在 guardrails 内快速迭代, 风险团队也能看到控制真实运行。

12. Scenario Simulation

用以下场景模拟训练 policy product management 判断:

Scenario	分析问题	期望输出
Credit	设计一个信贷政策 AI copilot 的 risk appetite statement	自动化边界、reason code 来源、人工确认、trace evidence
Wealth	判断客户自助财富问答是否可以上线	Advice boundary、持牌顾问转接、disclosure、越界监控
Customer service	把客服 AI 从员工草稿扩展到客户自助 FAQ	Tier 变化、release gate、投诉/申诉、route-to-human
AML	设计 AML case summarization assistant	Analyst-in-control、证据引用、禁止最终结论、审计证据
Agent	让 AI 调用 CRM 和账户工具	Tool permission、PDP/PEP、approval token、kill switch

13. Summary

AI Risk Appetite / Policy Product Management 的核心能力是把高层风险偏好转成产品事实:

Risk appetite 决定产品边界, 不是只写在治理文件里。
Risk tier 决定控制强度、上线门禁、证据要求和路线图速度。
Policy 要被产品化为可版本、可测试、可执行、可监控、可例外、可复核的控制资产。
Guardrails 要覆盖 advice、automation、data、tool、human oversight、disclosure 和 appeal。
Metrics 要连接 risk appetite indicators、KRIs、SLO、breach thresholds 和 stop rules。
Evidence binder 是 AI 产品能被 risk、audit、executive 和监管沟通理解的共同语言。
Roadmap 要按 risk capacity 排序: 先做可控价值, 再扩展自动化, 对 critical boundary 保持克制。

核心复盘:

Strong AI product governance turns risk appetite into shippable guardrails, measurable controls, reviewable evidence, and roadmap discipline.