AI Governance / EvalOps / RiskOps 90天计划

定位：面向金融零售 PM / BA / 架构师，补齐企业 AI 治理、评测工程与风险运营能力，目标岗位是 AI Solutions Architect / AI Business Architect。 原则：这是一条新的能力扩展线，不替代既有 Web3、架构、AI BA 学习资产；它专注把 AI 从“能演示”推进到“可上线、可审计、可运营、可改进”。

Source Baseline

以下资料作为学习锚点与术语校准来源，不构成法律意见、合规结论或监管解释。

使用方法：

• 先用 NIST AI RMF 建立治理语言：风险不是抽象担忧，而是可识别、可衡量、可分配责任、可持续管理的对象。
• 再用 EU AI Act 建立外部约束感：产品设计、系统架构、数据治理、供应商管理、上线流程都会被风险等级影响。
• 用 OWASP 把“LLM 很危险”拆成可测试攻击路径：提示注入、数据泄露、越权工具调用、供应链、过度代理能力等。
• 用 ISO/IEC 42001 训练体系化表达：政策、目标、角色、流程、证据、改进，而不是一次性的合规文档。

Why governance is now product and architecture work, not paperwork

AI 治理不再只是法务或合规部门的后置文件工作，原因有三层。

第一，AI 能力本身已经嵌入业务流程。客服摘要、贷款预审、KYC 辅助、反欺诈预警、营销推荐、财富顾问辅助、支付异常解释，都会直接改变客户体验、员工决策和业务风险。

第二，生成式 AI 与传统模型不同，输出具有概率性、上下文依赖和工具调用能力。一个产品需求如果没有定义可接受输出、不可接受输出、人工接管点、证据留存和回滚策略，就不是完整需求。

第三，企业 AI 的风险来自系统组合，而不只是模型。数据来源、RAG 检索、权限、提示词、工具、工作流、人工复核、日志、供应商、上线门禁、监控告警共同决定风险暴露。

因此，AI Governance 是产品工作：

• PM 要定义 AI 功能的目标用户、业务价值、边界、误用场景和上线门槛。
• BA 要把政策、监管、流程、数据、角色和例外路径转化成可执行需求。
• 架构师要把治理要求落到系统边界、数据流、控制点、日志、权限、评测和运维机制。

治理的成熟标志不是“有一份政策”，而是每次 AI 版本发布都能回答：

• 这个系统属于什么风险等级？
• 使用了哪些模型、数据、工具和供应商？
• 通过了哪些质量、安全、公平性、性能与成本门槛？
• 谁批准上线？谁监控？出事谁响应？
• 证据在哪里？能否复现当时的决策？

Governance stack: policy, risk taxonomy, model inventory, data lineage, eval gates, incident response, human oversight, audit evidence

企业 AI 治理栈可以分成八层，每层都要有产物、责任人和系统化证据。

这八层要避免两个误区：

• 误区一：只做政策，不做门禁。没有 Eval Gate 的政策无法阻止风险上线。
• 误区二：只做评测，不做责任。没有 Owner、SLA、事故流程和证据链，评测只是实验结果。

成熟治理应形成“政策到代码”的链路：

• 政策定义原则。
• 风险分类决定控制强度。
• 清单登记确定责任边界。
• 数据血缘确认输入合法性与可追溯性。
• Eval Gate 阻止不合格版本上线。
• 监控和事件响应覆盖生产风险。
• 审计证据支持内部审查、客户问责和监管沟通。

EvalOps stack: dataset, graders, thresholds, release gates, regression, red-team, production monitoring, feedback loop

EvalOps 是把 AI 质量、安全和业务效果做成工程化流水线，而不是靠人工抽查和主观感觉。

EvalOps 的核心产物不是一个分数，而是一套可重复的发布判断机制。

PM 关注：

• 评测集是否覆盖核心用户旅程？
• 指标是否对应真实业务价值？
• 阈值是否能支持上线决策？

BA 关注：

• 评测样本是否覆盖政策、流程、例外和角色？
• 评分规则是否可解释、可追溯？
• 失败案例是否能转化为需求或控制？

架构师关注：

• Eval 是否进入 CI/CD 或 LLMOps Pipeline？
• 日志是否支持复现？
• 测试数据、评分器和模型版本是否被版本化？

RiskOps stack: detection, triage, severity, owner, response, postmortem, control improvement

RiskOps 是 AI 风险的日常运营机制。它回答的不是“有没有风险”，而是“风险出现时我们如何发现、分级、处理、复盘和改进”。

RiskOps 成熟度可以用四个问题判断：

• 风险是否能被发现，而不是等客户或监管提醒？
• 风险是否能被分级，而不是所有问题都靠临时会议？
• 风险是否能被关闭，而不是只写复盘不改控制？
• 风险是否能反哺 EvalOps，而不是同类事故反复出现？

EU AI Act / NIST AI RMF / OWASP / ISO 42001 as learning anchors, not legal advice

本计划中的监管与标准内容只用于学习、产品设计和架构治理训练，不替代律师、合规官、审计师或监管顾问的专业判断。

四个锚点的学习定位：

• NIST AI RMF：学习风险管理语言，尤其是 Govern、Map、Measure、Manage 四类动作如何转成企业 AI 生命周期控制。
• EU AI Act：学习风险分级、透明度、人类监督、数据治理、技术文档、供应链责任等产品与架构影响。
• OWASP Top 10 for LLM Applications：学习 LLM 应用安全风险如何变成红队场景、测试用例和防护控制。
• ISO/IEC 42001：学习 AI 管理体系如何组织化，包括政策、角色、目标、审核、改进和证据管理。

面试表达建议：

• 不要说“我能给法律结论”。
• 要说“我能把监管和标准要求翻译成产品需求、架构控制、上线门禁、监控指标和审计证据”。
• 不要把治理等同为合规文档。
• 要强调治理是 AI 产品生命周期的一部分，贯穿需求、设计、开发、评测、上线、运营和退役。

Financial retail AI risk taxonomy: AML, KYC, lending, fraud, customer service, wealth, payments, compliance

金融零售 AI 风险分类要结合业务域、客户影响、监管敏感度和系统自主程度。

分类维度建议：

• 客户影响：是否影响开户、授信、交易、资金、投诉、财富建议。
• 自动化程度：建议型、辅助型、半自动、全自动。
• 可逆性：输出错误后是否可撤销、是否造成资金或权益损害。
• 敏感数据：是否涉及 PII、财务数据、身份材料、行为画像。
• 监管敏感度：是否涉及高风险决策、消费者保护、反洗钱、信贷公平。
• 可解释性要求：是否需要给客户、员工、审计或监管解释。

Required artifacts

90天结束后，至少要形成九类可展示作品集资产。

每个 Artifact 都要满足四个标准：

• 可复用：不是一次性笔记，而是模板或流程。
• 可审计：能说明来源、时间、责任人和证据。
• 可执行：能指导团队做决策或行动。
• 可面试：能在 3 分钟内讲清业务背景、设计取舍和结果。

Metrics and thresholds: quality, safety, fairness, latency, cost, drift, adoption, overrides, incidents

指标不是越多越好，而是要能触发决策。

阈值设计方法：

• 高风险金融决策优先用保守阈值，宁可人工复核更多，也不能自动化造成不可逆损害。
• 客服和内部助手可以分级放宽，但必须有引用、拒答、转人工和抽检机制。
• 阈值要随着生产数据迭代，但每次调整都要留存理由、批准人和影响评估。
• 指标要关联 Owner，不能只有 Dashboard 没有人负责。

90-day plan split into 9 ten-day blocks, each with learning, artifact, exercise, interview proof

Block 1: Day 1-10 - AI治理全景与角色定位

• Learning：建立企业 AI 生命周期视角：需求、数据、模型、系统、上线、监控、事故、退役；阅读 NIST AI RMF 概览，理解 Govern / Map / Measure / Manage；梳理金融零售 AI 用例地图，区分 Governance、MRM、MLOps、LLMOps、EvalOps、RiskOps。
• Artifact：完成《企业 AI 治理能力地图 v1》和《AI 用例清单模板》，字段包括业务域、用户、决策影响、数据、模型、Owner、风险等级。
• Exercise：选择“智能客服坐席助手”，画端到端流程和治理控制点，标注哪些控制属于产品需求、业务流程、系统架构和运营机制。
• Interview proof：形成 2 分钟回答：为什么 AI 治理不是 paperwork，而是产品和架构工作；能讲清 PM / BA / Architect 的责任边界。

Block 2: Day 11-20 - 风险分类与AI Risk Register

• Learning：深入 AML、KYC、Lending、Fraud、Customer Service、Wealth、Payments、Compliance 风险；学习影响、概率、可检测性、可逆性、自动化程度、监管敏感度；建立 Sev1-Sev4 严重级别。
• Artifact：完成《AI Risk Register v1》和《金融零售 AI 风险分类字典 v1》，覆盖风险描述、触发条件、控制、Owner、证据、剩余风险。
• Exercise：为 8 个金融零售 AI 用例各登记至少 5 条风险，每条风险必须写明预防控制、检测控制、纠正控制和上线影响。
• Interview proof：能解释“风险分类如何影响产品上线门槛和架构控制”，并用智能信贷辅助审批讲清风险登记表示例。

Block 3: Day 21-30 - 政策、控制包与ISO 42001式管理体系

• Learning：阅读 ISO/IEC 42001 overview，理解 AI 管理体系；学习政策到控制的映射：原则、流程、角色、系统控制、证据；梳理 AI 使用、供应商、数据、人工监督、模型变更政策。
• Artifact：完成《AI Control Pack v1》《AI Governance RACI Matrix》《AI Policy-to-Control Mapping》，让每条政策都能追溯到控制和证据。
• Exercise：以“财富顾问辅助生成投资解释”为例，设计预防、检测、纠正三类控制，区分系统强制控制与流程控制。
• Interview proof：能回答“如何把 AI 政策变成工程控制”，并说明 ISO/IEC 42001 的价值不是文档化，而是持续改进。

Block 4: Day 31-40 - EvalOps基础：数据集、评分器与阈值

• Learning：理解黄金样本、边界样本、对抗样本、回归样本、生产抽样；设计规则型、LLM-as-judge、人工专家、混合评分器；学习上线、观察、阻断、回滚阈值。
• Artifact：完成《AI Eval Policy v1》《客服 AI Eval Dataset Schema》《质量/安全/成本/延迟阈值表》，明确评分口径和失败处理。
• Exercise：为“投诉摘要生成”设计 50 条评测样本，覆盖正常、敏感、复杂、多语言、恶意输入，并设计事实一致性、遗漏、语气、隐私、引用、行动项 Rubric。
• Interview proof：能说明“为什么上线 AI 功能不能只看 demo 效果”，并讲清 Dataset、Grader、Threshold、Release Gate 的关系。

Block 5: Day 41-50 - Release Gate与回归体系

• Learning：学习模型升级、Prompt 修改、RAG 索引更新、工具权限变更、业务规则变化的治理差异；设计 Release Gate；建立 Regression、Canary、Feature Flag、Kill Switch 思维。
• Artifact：完成《AI Release Gate Checklist》《AI Regression Test Plan》《上线批准记录模板》，覆盖需求批准、风险评审、数据合规、安全测试、Eval 通过、Runbook 就绪、监控启用。
• Exercise：模拟 RAG 知识库更新导致错误政策回答，设计发布前发现、发布后监控、事故回滚和证据留存。
• Interview proof：能回答“一个企业 AI 系统上线前必须过哪些门”，并解释为什么 Prompt 变更也要进入变更管理。

Block 6: Day 51-60 - OWASP LLM安全与红队场景库

• Learning：阅读 OWASP Top 10 for LLM Applications，建立 LLM 攻击面地图；学习提示注入、敏感信息泄露、不安全输出处理、越权工具调用、过度代理能力、供应链风险。
• Artifact：完成《AI Red-team Scenario Bank》《LLM Application Security Control Pack》《Prompt Injection Test Suite v1》。
• Exercise：为“内部合规问答助手”设计 30 个红队场景，覆盖越权读取、绕过系统提示、伪造监管要求、诱导泄露客户数据、工具误调用。
• Interview proof：能用 OWASP 视角解释 LLM 应用安全风险，并说明红队结果如何进入 EvalOps、Risk Register 和 Control Pack。

Block 7: Day 61-70 - RiskOps事件响应与生产监控

• Learning：建立 AI Incident 分级和响应机制：Detection、Triage、Severity、Owner、Response、Postmortem、Control Improvement；学习 MTTD、MTTR、复发率、误报率、人工覆盖率、客户影响面。
• Artifact：完成《AI Incident Runbook》《AI Incident Severity Matrix》《Postmortem Template》，明确升级链路、止血动作、客户修复和控制更新。
• Exercise：模拟“客服 AI 错误承诺免除费用”的 Sev2 事件，写出检测、定级、止血、客户修复、根因分析、控制改进全过程。
• Interview proof：能回答“AI 生产事故如何处理”，并把事故复盘结果转成新的评测样本、控制和发布门禁。

Block 8: Day 71-80 - 模型/系统清单、数据血缘与审计证据

• Learning：学习 Model/System Inventory 字段：用途、Owner、版本、供应商、数据、风险等级、控制状态、评测结果；学习数据血缘、日志留存、供应商风险和证据管理。
• Artifact：完成《AI Model/System Inventory》《AI Data Lineage Map》《AI Audit Evidence Pack》，把需求、审批、风险评估、测试、上线、监控、事故、控制更新连接起来。
• Exercise：为“贷款申请材料智能审核助手”建立系统清单和数据流图，标注 PII、权限边界、日志脱敏、保留期限和证据位置。
• Interview proof：能回答“审计问你某个 AI 系统为什么可以上线，你如何拿证据”，并解释模型清单与 CMDB、数据目录、风险登记表的关系。

Block 9: Day 81-90 - 治理Dashboard、作品集与面试整合

• Learning：设计 AI Governance Dashboard：风险状态、Eval 通过率、事故趋势、红队覆盖率、人工覆盖、成本、延迟、采用率；学习管理层汇报和面试故事线。
• Artifact：完成《AI Governance Dashboard Spec》《90天 Capstone：金融零售企业 AI 治理与 EvalOps 蓝图》《面试问答集 v1》。
• Exercise：选择“银行智能客服 + KYC 辅助 + 投诉摘要”综合场景，输出用例、风险、控制、评测、上线、监控、事故、审计的端到端治理蓝图。
• Interview proof：准备 10 分钟作品集讲解，并能根据面试官角色切换表达：对 CTO 讲架构，对 CPO 讲产品价值，对 CRO/Compliance 讲控制和证据。

How BA/PM/Architect collaborate in governance

AI 治理需要三类角色协同，而不是互相甩锅。

协作原则：

• PM 不把风险丢给合规，而是把风险纳入产品边界和上线标准。
• BA 不只写需求文档，而是把政策、流程、控制和证据串成可执行闭环。
• Architect 不只选模型和框架，而是把治理要求内建到系统设计里。
• 三者共同维护一个事实源：用例清单、风险登记、评测结果、发布记录、事故记录和证据包。

Portfolio packaging for AI Solutions Architect / AI Business Architect

90天后建议形成一个独立作品集文件夹，包含：

• 01_ai_governance_blueprint.md：企业 AI 治理蓝图。
• 02_ai_risk_register.xlsx 或 Markdown 表格：风险登记与控制映射。
• 03_eval_policy.md：评测政策、样本设计、阈值和发布门禁。
• 04_release_gate_checklist.md：上线检查清单。
• 05_incident_runbook.md：事件响应流程。
• 06_model_inventory.md：模型/系统清单模板。
• 07_red_team_scenarios.md：红队场景库。
• 08_audit_evidence_pack.md：审计证据包结构。
• 09_governance_dashboard_spec.md：治理 Dashboard 指标与线框说明。

作品集叙事：

• 背景：金融零售企业正在将 AI 嵌入客服、风控、信贷、合规和运营。
• 问题：AI 试点多，但缺少统一风险语言、评测门禁、事故响应和审计证据。
• 方案：建立 Governance + EvalOps + RiskOps 三层闭环。
• 结果：每个 AI 系统有 Owner、风险等级、控制、阈值、发布记录、监控和证据。
• 价值：让企业 AI 从零散试验变成可规模化、可问责、可持续改进的能力。

50 deep questions for future study

1. 企业应该如何区分 AI 系统、模型、工作流和普通自动化规则？
2. 一个 AI 用例的风险等级应该由谁决定，业务、风险、合规还是架构委员会？
3. 风险等级是否应该随模型能力、数据范围和自动化程度动态变化？
4. AI Risk Register 如何避免变成没人维护的静态表格？
5. 什么情况下 AI 输出必须强制人工复核？
6. 如何定义“人类监督”是有效的，而不是形式化点击批准？
7. 对客户有直接影响的 AI 建议，如何设计申诉和纠错机制？
8. 信贷 AI 的公平性指标应该如何结合业务合理性和监管敏感度？
9. KYC 场景中，AI 误判身份材料的可接受阈值应该如何设定？
10. AML 告警摘要如果遗漏关键信息，责任应如何分配？
11. 财富管理场景中，投教、建议、推荐和销售之间的边界如何划清？
12. 客服 AI 的“错误承诺”应该如何监控和补救？
13. 支付风控模型漂移时，应该优先保护通过率还是风险拦截率？
14. 如何设计既能保护隐私又能支持 EvalOps 的测试数据集？
15. LLM-as-judge 在金融场景中可以信到什么程度？
16. 哪些评测必须人工专家参与，不能完全自动化？
17. Prompt 变更是否需要与代码变更同等的审批和回归？
18. RAG 知识库更新如何纳入变更管理？
19. 如何证明一个 AI 系统的输出可以复现？
20. 如果供应商模型不可解释，企业还能如何建立可审计证据？
21. AI Dashboard 应该给董事会、CRO、CIO、产品负责人分别展示什么？
22. AI 事故的 Severity 应该按技术错误、客户影响还是监管风险分级？
23. 什么情况下需要立即关闭 AI 功能，而不是灰度降级？
24. AI 事故复盘如何避免只追责个人而不改系统控制？
25. 红队测试发现的问题是否都必须阻断上线？
26. 如何把 OWASP LLM 风险转成开发团队能执行的安全需求？
27. 工具调用型 Agent 的权限边界应该如何设计？
28. 内部员工使用 AI 助手时，如何防止越权查询和数据外泄？
29. AI 生成的合规政策摘要如何处理法规更新和版本冲突？
30. AI 供应商评估应该覆盖哪些技术、法律、数据和运营问题？
31. 企业 AI 管理体系如何和现有 ITSM、GRC、MLOps、Data Governance 连接？
32. ISO/IEC 42001 的管理体系思路如何落到日常产品迭代？
33. NIST AI RMF 的 Govern 如何避免停留在委员会层面？
34. EU AI Act 风险分级对金融 AI 产品路线图有什么影响？
35. 如何在不提供法律意见的前提下，把监管要求转成产品和架构需求？
36. AI 模型清单与系统清单、数据目录、API 目录之间如何建立关联？
37. AI 审计证据应该保存多久，谁有权限查看？
38. AI 日志如何在可追溯、隐私保护和成本之间权衡？
39. 如果模型输出质量提升但成本翻倍，发布决策如何做？
40. 如果采用率低但风险控制优秀，是否算成功？
41. 人工覆盖率上升是风险信号、培训问题还是模型退化？
42. 如何衡量 AI 治理对业务价值的贡献，而不只是合规成本？
43. 如何设计 AI Governance Dashboard 的 North Star Metric？
44. 哪些 AI 风险适合自动检测，哪些必须依赖人工抽检？
45. 多地区、多语言 AI 系统的治理如何处理本地差异？
46. 金融零售企业如何建立 AI 红队能力，是集中团队还是嵌入产品线？
47. AI 控制包如何保持轻量，避免拖慢所有创新？
48. 如何让一线运营人员参与反馈闭环，而不是只由技术团队改模型？
49. AI Business Architect 在企业中应向 CIO、CDO、CRO 还是业务线汇报？
50. 未来 Agentic AI 普及后，企业治理栈最需要新增哪三类控制？