AI Risk Appetite / Policy Product Management 解读

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

---

Source Anchors

核心导读

AI risk appetite 如果停留在董事会或政策文件里, 产品团队仍然不知道哪些能力能做、做到什么程度、需要什么证据才能上线。成熟做法是把风险偏好产品化: 转成 risk tier、product guardrails、runtime controls、breach thresholds、exception process 和 stop rules。

这篇的核心判断是: 风险政策不是上线前审批材料, 而应成为 AI 产品和平台每天执行的控制面。

问题定义

抽象风险偏好通常长这样:

• 不接受未披露的客户权益自动化决策。
• 对敏感客户数据外发零容忍。
• 允许低风险内部效率场景快速试验。
• 只有在人工复核和审计证据充分时, 才允许生成式 AI 支持受监管沟通。

产品和架构团队需要更具体的答案:

• 这个功能属于什么 risk tier。
• 是否可以直接面向客户。
• 是否允许自动执行。
• 是否允许生成建议或推荐。
• 是否能使用客户 PII, 是否可外发。
• 是否需要人工审批、披露、申诉和回滚。
• 需要哪些 eval、日志、监控和 evidence。
• 什么指标触发暂停、降级或重新审批。

转译链应是:

Enterprise risk appetite
  -> AI policy intent
  -> Product guardrails
  -> Architecture controls
  -> Runtime enforcement
  -> Monitoring and evidence
  -> Review / exception / stop rule

核心原理/方法

Risk-tiered product management 是把风险偏好变成产品规则:

risk tier 不是标签, 它决定:

• MVP 能做什么和不能做什么。
• release gate 的强度。
• 哪些证据必须生成。
• 谁可以批准例外。
• 哪些指标必须持续监控。
• 何时自动暂停或降级。

AI policy 要像产品一样管理 lifecycle:

Policy intent
  -> Rule / control design
  -> Product requirement
  -> Architecture implementation
  -> Runtime guardrail
  -> Monitoring
  -> Exception
  -> Review and update

系统/架构模型

风险偏好应落到 control plane:

Product experience
  -> disclosure / consent / appeal / handoff
Workflow and orchestration
  -> risk tier / approval / escalation / rollback
Model and data access
  -> model allowlist / DLP / PII redaction / retention
Tool gateway
  -> least privilege / side-effect policy / idempotency / audit
Policy engine
  -> allow / deny / redact / escalate / pause
Observability
  -> KRI / SLO / drift / breach alert
Evidence store
  -> eval result / approval / decision trace / exception expiry

Product guardrails 与架构实现的映射:

关键机制与取舍

风险偏好产品化的难点是速度与控制的平衡:

成熟组织不会让每个团队自己解释风险偏好, 而是把 guardrail catalog、policy service、control matrix 和 exception playbook 作为可复用能力。

证据与控制

风险偏好必须量化成可监控指标:

Stop rule 示例:

If high-risk customer-facing AI produces:
  - confirmed policy breach above threshold, or
  - PII exposure incident, or
  - appeal upheld rate doubles baseline, or
  - human review SLA breach creates customer harm,
then:
  pause automation,
  downgrade to assist-only,
  notify risk owner,
  run incident review,
  require release re-approval.

Evidence 应包括 risk tier rationale、eval result、control mapping、approval record、monitoring threshold、exception expiry 和 incident learning。

AI产品/金融零售场景

AI wealth assistant

组织可接受:

• 教育性解释。
• 组合信息摘要。
• 风险问卷材料检查。
• 顾问会前准备。

组织不可接受:

• AI 独立给出个性化投资建议。
• AI 给出适当性结论。
• AI 推荐购买具体产品。
• AI 绕过 licensed advisor。

产品边界:

这说明 roadmap 不是由“AI 能做什么”决定, 而是由组织愿意承担什么风险决定。第一版可以做资料摘要和教育问答, 不做自动推荐和适当性结论。

信贷解释助手

风险偏好应禁止 AI 生成与真实决策逻辑不一致的 adverse action reason。产品必须使用 decision trace、approved reason code、人工复核和申诉路径; 架构必须保留政策版本、输入特征、规则/模型输出和生成文本之间的可追溯关系。

反模式

最终心智模型

AI risk appetite 的最终心智模型是:

风险偏好定义组织愿意承担什么风险;
policy intent 定义原则;
product guardrails 定义用户和流程边界;
architecture controls 定义运行时执行;
metrics and stop rules 定义持续 assurance;
exception process 定义有条件越界和复审。

成熟的 AI 产品管理不是在创新和合规之间二选一, 而是把风险偏好做成可复用、可执行、可监控的产品与平台能力, 让低风险场景快, 高风险场景稳, 越界场景可见且可回收。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。