AI 扩展计划 / Playbooks

AI Governance / EvalOps / RiskOps 90 天计划

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

366 行AI_GOVERNANCE_EVALOPS_RISK_90_PLAN.md

AI Governance / EvalOps / RiskOps 90天计划

定位：金融零售企业 AI 治理、评测工程与风险运营系统学习计划。原则：这是一条新的能力扩展线，不替代既有 Web3、架构和 AI 学习资产；它专注把 AI 从“能演示”推进到“可上线、可审计、可运营、可改进”。定位更新（2026-07-01 执行仲裁）：本计划为素材库，被 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 模块 4/8 吸收，按模块选读；不作为并行的 90 天计划执行。

Source Baseline

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

来源	官方链接	学习用途
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	用 Map / Measure / Manage / Govern 建立 AI 风险管理闭环
EU AI Act	https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai	理解风险分级、供应链责任、透明度、人类监督与高风险系统要求
OWASP Top 10 for LLM Applications	https://owasp.org/www-project-top-10-for-large-language-model-applications/	识别 LLM 应用安全风险、攻击面、红队场景与控制措施
ISO/IEC 42001	https://www.iso.org/standard/42001	理解 AI 管理体系、组织治理、持续改进与审计证据

使用方法：

先用 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 是产品、流程和架构共同承担的系统工作：

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

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

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

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

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

层级	核心问题	关键产物	架构落点
Policy	我们允许 AI 做什么，不允许做什么？	AI 使用政策、模型采购政策、数据使用规则	门户、审批流、策略库
Risk taxonomy	风险如何分类、评级和升级？	AI 风险分类、严重级别、控制映射	风险登记、标签体系
Model inventory	企业有哪些 AI 系统和模型？	模型/系统清单、Owner、用途、版本	CMDB、Model Registry、资产台账
Data lineage	输入数据从哪里来，是否合规可追溯？	数据血缘、数据分类、PII 标记、授权依据	数据目录、RAG 索引元数据
Eval gates	什么结果才允许上线？	Eval Policy、门禁清单、阈值、测试报告	CI/CD、LLMOps Pipeline
Incident response	发现事故后如何处理？	AI 事件 Runbook、升级机制、通报模板	告警、工单、战情室
Human oversight	什么时候必须人工介入？	人工复核规则、覆盖率、Override 记录	审批队列、案例管理
Audit evidence	如何证明我们做过治理？	证据包、审批记录、测试结果、日志样本	审计仓库、不可篡改日志

这八层要避免两个误区：

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

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

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

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

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

层级	说明	金融零售示例
Dataset	代表真实业务场景、边界场景和风险场景的数据集	客服咨询、贷款拒绝解释、KYC 材料缺失、支付争议
Graders	自动或人工评分器，判断输出是否达标	正确性评分、安全评分、合规语言评分、引用命中率
Thresholds	发布必须满足的最低门槛	准确率、拒答率、幻觉率、PII 泄露率、延迟、成本
Release gates	上线前检查点	PRD 审批、风险评审、Eval 通过、Runbook 完成
Regression	防止新版本破坏旧能力	Prompt、模型、RAG 索引、工具变更后的回归测试
Red-team	主动攻击和滥用测试	提示注入、越权查询、伪造 KYC、绕过 AML 控制
Production monitoring	生产环境持续观测	质量抽检、异常输出、投诉、人工覆盖、成本漂移
Feedback loop	把事故、反馈和误判转成改进	新测试样本、阈值调整、控制优化、训练/检索改进

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

产品价值视角关注：

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

流程证据视角关注：

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

架构师关注：

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

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

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

环节	关键动作	典型产物
Detection	从监控、抽检、用户投诉、员工反馈、红队测试发现问题	告警规则、异常样本、风险工单
Triage	判断是否真实、是否重复、是否影响客户或监管义务	初筛记录、影响面分析
Severity	按影响范围、客户损害、合规风险、可逆性定级	Sev1-Sev4 标准
Owner	指派业务、产品、技术、合规、模型或供应商责任人	RACI、值班表、升级链路
Response	停用、降级、回滚、人工接管、客户沟通、根因排查	Incident Runbook、沟通模板
Postmortem	分析根因、缺失控制、检测滞后、流程漏洞	复盘报告、行动项
Control improvement	把事故转化为新控制、新评测、新阈值、新培训	控制包更新、测试集更新

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 风险分类要结合业务域、客户影响、监管敏感度和系统自主程度。

领域	典型 AI 用例	主要风险	必备控制
AML	可疑交易摘要、告警优先级、案件辅助调查	漏报、误报、解释不充分、名单误匹配	人工复核、证据链、规则与模型双轨、案例抽检
KYC	材料识别、客户尽调知识检索、风险等级建议	身份误判、资料泄露、偏见、越权查看	数据最小化、权限隔离、EDD 触发、审计日志
Lending	授信辅助、拒绝原因解释、收入核验	歧视、公平性、错误拒贷、不可解释	Fairness 测试、模型卡、人工申诉、原因码
Fraud	交易欺诈检测、设备风险、异常行为解释	漏拦、误拦、攻击者适应、漂移	实时监控、Champion/Challenger、阈值治理
Customer service	智能客服、坐席辅助、投诉摘要	幻觉、错误承诺、敏感信息泄露、语气不当	知识库引用、拒答策略、人工转接、质检抽样
Wealth	投教、产品匹配、组合解释	不当建议、风险等级不匹配、收益误导	适当性检查、免责声明、人工确认、内容审查
Payments	支付争议处理、异常解释、路由优化	错误拒付、延迟、欺诈绕过、合规报告缺失	SLO、回滚、双人审批、高风险队列
Compliance	政策检索、监管变化摘要、控制映射	法规误读、过期知识、证据缺失	来源引用、版本管理、合规复核、变更记录

分类维度建议：

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

Core system artifacts

90天结束后，至少要形成九类系统学习资产。

Artifact	内容	学习价值
AI risk register	用例、风险、等级、控制、Owner、状态、证据链接	训练风险运营能力, 而不只是识别风险
Control pack	每类风险对应的预防、检测、纠正控制	训练把治理落到流程和系统
Eval policy	评测范围、数据集、评分器、阈值、失败处理	训练 EvalOps 的发布治理价值
Release gate checklist	上线前必须通过的政策、风险、评测、安全、运维检查	训练 AI 上线门禁设计
Incident runbook	分级、响应、回滚、沟通、复盘、改进流程	训练生产风险处理
Model/system inventory	模型、系统、Owner、供应商、数据、用途、版本、风险等级	训练 AI 资产治理
Red-team scenario bank	攻击场景、测试步骤、预期控制、结果记录	训练 LLM 安全与滥用风险分析
Audit evidence pack	审批、测试、日志、样本、版本、复盘、控制更新	训练审计和管理层问责证据
Governance dashboard	风险、评测、事故、覆盖率、成本、采用率、趋势	训练治理产品化和运营化

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

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

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

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

指标类别	示例指标	阈值示例	触发动作
Quality	正确率、引用命中率、任务完成率、人工评分	核心场景正确率 >= 95%	不达标禁止上线
Safety	PII 泄露率、越权回答率、危险建议率	高风险场景 0 Critical	Critical 立即阻断
Fairness	不同群体通过率差异、拒绝原因一致性	差异超过设定阈值需复核	进入公平性评审
Latency	P50/P95/P99 响应时间	P95 <= 3 秒	降级、缓存或架构优化
Cost	每请求成本、每任务成本、月度预算偏差	超预算 15% 告警	模型路由或压缩
Drift	输入分布、拒答率、命中知识库变化	连续 7 天异常	触发回归评测
Adoption	使用率、活跃员工、任务渗透率	低于目标 30%	访谈和流程调整
Overrides	人工覆盖率、覆盖原因、覆盖后正确率	覆盖率异常上升	检查模型或流程
Incidents	Sev1-Sev4 数量、MTTD、MTTR、复发率	Sev1 零容忍	立即升级管理层

阈值设计方法：

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

90-day plan split into 9 ten-day blocks

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：选择“智能客服坐席助手”，画端到端流程和治理控制点，标注哪些控制属于产品需求、业务流程、系统架构和运营机制。
Evidence check：能用一张 lifecycle map 说明 AI 治理不是 paperwork，而是需求、流程、架构、评测、上线、运营和证据的闭环。

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 条风险，每条风险必须写明预防控制、检测控制、纠正控制和上线影响。
Evidence check：能用智能信贷辅助审批说明风险分类如何影响上线门槛、架构控制和证据要求。

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：以“财富顾问辅助生成投资解释”为例，设计预防、检测、纠正三类控制，区分系统强制控制与流程控制。
Evidence check：能把一条 AI policy 映射到 workflow control、technical control、owner、metric、evidence 和 review cadence。

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

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

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 知识库更新导致错误政策回答，设计发布前发现、发布后监控、事故回滚和证据留存。
Evidence check：能把 Prompt、RAG、tool、model、threshold 变更分别映射到 release gate、regression、approval 和 rollback。

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 个红队场景，覆盖越权读取、绕过系统提示、伪造监管要求、诱导泄露客户数据、工具误调用。
Evidence check：能说明红队结果如何进入 EvalOps、Risk Register、Control Pack 和 release decision。

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 事件，写出检测、定级、止血、客户修复、根因分析、控制改进全过程。
Evidence check：能把一次 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、权限边界、日志脱敏、保留期限和证据位置。
Evidence check：能用 inventory、data lineage、release record、eval report、trace sample 说明某个 AI 系统为什么可以上线。

Block 9: Day 81-90 - 治理Dashboard与Capstone整合

Learning：设计 AI Governance Dashboard：风险状态、Eval 通过率、事故趋势、红队覆盖率、人工覆盖、成本、延迟、采用率；学习管理层汇报和系统叙事。
Artifact：完成《AI Governance Dashboard Spec》《90天 Capstone：金融零售企业 AI 治理与 EvalOps 蓝图》《系统学习复盘 v1》。
Exercise：选择“银行智能客服 + KYC 辅助 + 投诉摘要”综合场景，输出用例、风险、控制、评测、上线、监控、事故、审计的端到端治理蓝图。
Evidence check：能用同一个 capstone 说明治理栈、EvalOps、RiskOps、release gate、incident loop 和 audit evidence 如何闭环。

Governance collaboration model

AI 治理需要价值边界、流程证据和架构控制协同，而不是互相甩锅。

事项	价值边界	流程证据	架构控制
用例定义	定义目标、价值、用户旅程、成功指标	拆流程、角色、规则、例外、合规约束	判断系统边界、集成方式、非功能需求
风险分类	判断客户影响和业务优先级	维护风险场景、政策映射、操作流程	设计控制点、隔离边界、日志和权限
EvalOps	定义业务指标和上线门槛	设计样本、Rubric、人工质检流程	实现评测流水线、版本化、监控
Release Gate	决定是否达到产品发布标准	检查需求、流程、证据完整性	检查架构、安全、性能、回滚
Incident	对客户体验和业务影响负责	协调流程、根因、补救和文档	负责止血、回滚、监控、技术根因
Dashboard	关注采用率、价值、风险趋势	关注流程 SLA、证据、控制覆盖	关注系统健康、延迟、成本、漂移

协作原则：

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

Capstone packaging

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

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 指标与线框说明。

Capstone 叙事：

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

Long-term study map

这组长期议题用于 90 天之后继续深化。使用方式不是逐条背答案, 而是把每个议题连接到一个 use case、一个风险场景、一组 eval、一套控制和一份证据。

Theme	Study focus
System boundary	区分 AI system、model、workflow、ordinary automation rule, 并说明 inventory、owner、version、risk tier 如何分层登记。
Dynamic risk tiering	研究风险等级如何随模型能力、数据范围、自动化程度、客户影响和监管敏感度变化。
Risk register operations	让 AI Risk Register 成为 issue management、release gate、monitoring 和 control improvement 的活表, 而不是静态表格。
Effective human oversight	定义强制人工复核、有效挑战、override、edit diff、review capacity、customer appeal 和 correction loop。
Lending fairness	把信贷公平性指标、业务合理性、原因码一致性、申诉机制和监管敏感度连接起来。
KYC and AML evidence	研究身份材料误判阈值、AML alert summary omission、SAR narrative support、责任边界和抽样复核。
Wealth boundary	划清投教、建议、推荐和销售之间的边界, 并设计 suitability、disclosure、human confirmation 和 content review。
Customer service harm	监控和补救错误承诺、错误费用减免、错误投诉分类、敏感信息泄露和 repeat contact。
Payment risk drift	在支付风控漂移时平衡通过率、误拦、漏拦、欺诈损失、客户体验和实时止损。
Eval data privacy	设计既保护隐私又支持 EvalOps 的测试数据集, 包括 synthetic data、redaction、access、retention 和 sampling。
Grader reliability	校准 LLM-as-judge、规则评分、专家评分和混合评分器, 明确哪些评测不能完全自动化。
Change governance	把 prompt、RAG、tool、threshold、model、vendor 和 policy 变更纳入 release-controlled 范围。
Reproducibility	证明 AI 输出可复现, 需要 prompt version、model route、index snapshot、tool result、policy decision 和 human action。
Vendor opacity	在供应商模型不可解释时, 用 contract、eval、monitoring、route control、fallback 和 incident record 建立可审计证据。
Executive dashboard	区分董事会、CRO、CIO、产品负责人和运营负责人需要看到的治理指标与行动阈值。
Incident severity	按客户影响、监管风险、可逆性、影响范围和检测延迟定义 AI incident severity。
Kill switch criteria	明确立即关闭、灰度降级、route fallback、manual queue 和 post-incident re-entry 的触发条件。
Red-team governance	把 OWASP LLM 风险转成开发需求、red-team scenario、eval sample、control pack 和 release blocker。
Agent authority	设计 tool-calling Agent 的 read、draft、write、submit、approve、reverse 权限边界和 idempotency。
Internal assistant leakage	防止员工助手越权查询、跨租户泄露、prompt injection、日志暴露和供应商外发。
Policy summarization	处理法规更新、政策版本冲突、source freshness、citation support 和合规复核。
Third-party risk	覆盖供应商技术、法律、数据、运营、subprocessor、region routing、SLA、exit plan 和 fallback test。
Enterprise integration	把 AI management system 连接到 ITSM、GRC、MLOps、Data Governance、model inventory 和 audit evidence store。
Regulatory translation	在不提供法律意见的前提下, 把监管要求转成产品边界、架构控制、上线门禁、监控指标和审计证据。
Evidence retention	在可追溯、隐私保护、成本、数据主体权利和审计要求之间设计日志与证据保留。
Cost-quality tradeoff	处理模型质量提升但成本翻倍、采用率低但控制优秀、人工覆盖率异常上升等治理取舍。
Governance value	衡量 AI 治理对业务价值的贡献: escaped defect reduction、release velocity、incident recurrence、control automation 和 trust。
Multi-region operation	处理多地区、多语言 AI 系统的本地政策、数据边界、eval sample、fallback 和 reviewer capacity。
Frontline feedback	让一线运营人员参与 feedback loop, 把 override、complaint、QA defect 和 incident sample 转成 eval 与控制更新。
Agentic future controls	面向 Agentic AI 增加 memory governance、tool chain approval、multi-agent coordination、budget guard 和 autonomous action limits。