跳到主要内容

AI 治理与风险管理

问题​

企业如何建立 AI 应用清单、风险分级、数据与模型治理、供应商审查、发布门禁、人工监督和事件响应，让 AI 从 Demo 走向可持续生产？

面试速答版

AI 治理不是在模型外加一个“敏感词过滤器”，而是覆盖整个生命周期：

  1. Govern：明确政策、角色、责任、培训和可接受风险。
  2. Map：登记用例、用户、数据流、模型、工具、供应商和潜在影响。
  3. Measure：通过评测、红队、监控和审计测量质量、安全与公平风险。
  4. Manage：按风险分级决定上线门禁、人工复核、灰度、回滚和事件处置。

核心原则是：模型输出只是建议，授权、金额、资格、删除和执行动作等关键决定必须有确定性控制与可追责的责任人。

法律提示

本文提供工程治理框架，不构成法律意见。AI 法规、行业要求和地域规则持续变化；涉及个人信息、就业、医疗、金融、未成年人或跨境数据时，应由法务、隐私与安全团队确认当前适用要求。

一、治理的目标​

好的治理不是阻止创新，而是让团队知道：

  • 哪些 AI 用例可以快速实验。
  • 哪些用例需要更严格评审和人工监督。
  • 谁对数据、模型、产品决策和事故负责。
  • 出现质量退化、越权或数据泄漏时如何发现与回滚。
  • 如何向用户说明 AI 的能力、限制和申诉渠道。

二、建立 AI 系统清单​

连“有哪些 AI”都不知道，就无法治理。清单不仅登记基础模型，还要登记完整应用：

types/ai-system-record.ts
interface AISystemRecord {
  id: string;
  name: string;
  owner: string;
  purpose: string;
  users: string[];
  riskTier: 'low' | 'medium' | 'high' | 'prohibited';
  models: Array<{ provider: string; model: string; version: string }>;
  dataClasses: Array<'public' | 'internal' | 'confidential' | 'restricted'>;
  tools: Array<{ name: string; sideEffect: boolean }>;
  vendors: string[];
  humanOversight: string;
  evalVersion: string;
  deployment: string;
  lastReviewAt: string;
}

清单应关联 Prompt、RAG 数据源、Embedding、Reranker、工具、Adapter、安全策略和评测版本。模型没变但 Prompt 或知识库变了，也可能构成实质性发布变更。

三、风险分级​

风险不是只按“模型强不强”划分，而要看使用环境和潜在影响：

级别示例常见控制
低文案草稿、内部头脑风暴明确 AI 标识、基础监控、不得输入敏感数据
中客服建议、代码辅助、内部知识问答评测、引用、权限、人工纠错、灰度和审计
高影响资格、金额、医疗/就业/金融决策严格审批、专家复核、解释与申诉、持续监测
禁止无合法依据的监控、绕过用户授权等阻止建设或上线

评估维度包括：

  • 错误是否会造成人身、财产、机会或权利影响。
  • 是否处理敏感数据，是否涉及未成年人或脆弱群体。
  • 输出是否直接触发不可逆副作用。
  • 用户能否识别、纠正、退出或申诉。
  • 系统覆盖范围、自动化程度和失败可恢复性。

风险分级要决定具体门禁，不应只是报告里的一个颜色标签。

四、角色与责任​

角色主要责任
业务 Owner用例目标、可接受风险、最终业务责任
产品与研发需求边界、架构、测试、监控和用户体验
数据 Owner数据合法来源、质量、权限、保留和删除
模型/平台团队模型能力、版本、网关、评测和可观测性
安全与隐私威胁建模、红队、事件响应和数据保护
法务/合规适用义务、合同、告知和记录要求
人工审核者按 Rubric 复核，能拒绝模型并反馈问题

一个 RACI 表必须落到具体姓名或团队。不能把所有责任写成“AI 团队负责”，也不能把模型供应商当作最终责任人。

五、数据治理​

数据流映射​

从浏览器到 Provider、日志和训练回流画出完整路径：

每条路径明确：数据分类、目的、合法依据、处理方、地域、加密、保留时间、删除方式和访问审计。

最小化与用途限制​

  • 只发送完成任务所需字段，先在服务端脱敏。
  • 密钥、Cookie、完整数据库记录不进入 Prompt。
  • 日志默认记录元数据、哈希和分类，而不是完整内容。
  • 线上内容用于评测或训练需要单独授权和治理流程。
  • 用户删除请求要覆盖缓存、向量库、日志和派生数据。

RAG 数据​

  • 检索必须继承源系统 ACL，并在查询时做资源级授权。
  • 记录来源、版本、更新时间和解析血缘。
  • 对投毒、恶意指令、错误文档和过期政策建立反馈与下架流程。
  • 引用不是装饰，必须能定位到用户有权访问的证据。

六、模型与供应商治理​

供应商审查​

不要只看模型榜单，至少确认：

  • 输入输出是否用于训练、默认保留多久、能否关闭存储。
  • 数据处理地域、子处理方、加密和访问控制。
  • 可用性、限流、版本弃用、事故通知与退出方案。
  • 模型卡、安全评估、内容政策和审计材料。
  • 合同是否覆盖数据删除、责任、知识产权和迁移。

版本与变更管理​

types/ai-release.ts
interface AIRelease {
  releaseId: string;
  appVersion: string;
  modelVersion: string;
  promptVersion: string;
  retrievalVersion?: string;
  toolPolicyVersion?: string;
  evalReport: string;
  approvers: string[];
  rollbackTarget: string;
}

供应商的模型别名可能指向新版本。高风险系统应固定可识别版本或建立别名变更的自动回归和门禁。

七、评测、红队与发布门禁​

分层评测​

  • 能力：任务成功、准确、召回、结构化输出。
  • 安全：Prompt Injection、数据泄漏、越权工具、恶意 URL。
  • 公平与影响：关键群体和边界切片，不用平均分掩盖失败。
  • 运行：延迟、成本、可用性、取消和降级。
  • 人工监督：审核者是否看得懂证据，是否能覆盖并纠正模型。

红队范围​

  • 直接和间接 Prompt Injection。
  • 权限混淆、跨租户缓存和工具参数篡改。
  • 敏感数据提取、系统 Prompt 套取和日志泄漏。
  • 高成本输入、循环工具和拒绝服务。
  • 误导性引用、虚构证据和对审核者的自动化偏见。

发布门禁应由风险级别决定。高风险用例至少需要关键切片零容忍、人工批准、灰度范围、回滚负责人和明确停止条件。

八、人工监督不是“点一下确认”​

有效的人类在环需要：

  • 审核者具备知识、时间和权限，而不是被迫快速批准。
  • UI 同时展示输入、证据、模型建议、不确定性和影响范围。
  • 高风险操作显示精确参数与 Diff，不使用模糊的“一键同意”。
  • 审核者可以修改、拒绝、升级和报告问题。
  • 记录谁在何时基于什么信息批准，避免自动化偏见。

对于高频低风险操作，可以通过策略自动批准；关键是由确定性规则决定，而不是让模型自己声称“这是低风险”。

九、用户透明度与体验​

  • 在会影响理解或决策的地方明确说明使用了 AI。
  • 说明系统能做什么、不能做什么和信息来源。
  • 重要回答提供引用、日期和验证方法。
  • 提供纠错、转人工、退出自动化和申诉渠道。
  • 不用拟人化文案暗示模型拥有不存在的理解或保证。
  • AI 生成内容进入外部发布前，按风险进行人工审核与标记。

十、线上监控与事件响应​

要监控什么​

  • 任务成功、纠错、转人工、申诉和用户伤害信号。
  • 越权尝试、注入命中、敏感输出和工具拒绝。
  • 模型、Prompt、检索和数据源版本漂移。
  • 延迟、成本、循环、重试和供应商异常。
  • 不同语言、地区、群体和风险切片的质量变化。

事件响应流程​

Kill switch 要能按功能、租户、模型、工具或数据源精确关闭。事故发生后保存必要证据，但仍遵守最小化和保留政策。

十一、治理文档最小集合​

  • AI 系统卡：用途、用户、限制、Owner 和风险级别。
  • 数据卡：来源、许可、质量、敏感性、保留和删除。
  • 模型卡/供应商评估：能力、限制、版本与退出策略。
  • 威胁模型与隐私影响评估。
  • Eval 报告、红队报告和发布审批记录。
  • 人工监督 SOP、用户告知和申诉流程。
  • 监控、回滚和事件响应 Runbook。

文档应由流水线自动关联真实制品版本，避免上线系统与审批材料脱节。

十二、常见反模式​

  • 只建立伦理原则，没有系统清单、Owner 和执行门禁。
  • 认为购买知名模型后，供应商替自己承担全部风险。
  • 把模型输出过滤当作唯一安全层。
  • 高风险决策保留一个形式化“确认按钮”，审核者却没有证据。
  • 完整记录用户 Prompt，声称是为了“以后训练”。
  • 只在上线前评估一次，忽略模型别名和知识库持续变化。
  • 用总平均分掩盖某个群体或权限切片的严重失败。
  • 事故发生时只能关闭整个产品，没有细粒度开关和回滚。

十三、面试常见问题​

Q1：AI 治理和 AI 安全有什么区别？​

答案：安全关注攻击、泄漏和滥用等风险；治理覆盖责任、清单、数据、供应商、评测、发布、透明度和事件等完整生命周期，安全是治理的一部分。

Q2：为什么要建立 AI 系统清单？​

答案：它让组织知道哪些用例处理哪些数据、调用哪些模型和工具、由谁负责，以及何时需要复审、停止或通知用户。

Q3：如何给 AI 用例分级？​

答案：综合潜在伤害、数据敏感度、自动化程度、影响规模、可逆性和人工纠正能力；分级结果必须映射到真实控制和审批。

Q4：模型版本没变，还需要重新评估吗？​

答案：需要视变更而定。Prompt、RAG 数据、工具、权限、量化和 Provider 行为都可能改变系统结果，应按实质影响触发回归。

Q5：Human-in-the-loop 为什么可能失效？​

答案：审核者没有时间、证据或否决权时，确认会变成走过场；自动化偏见还会让人过度相信看似专业的答案。

Q6：如何治理线上 Prompt 日志？​

答案：默认不存原文，只记录必要元数据；确需采样时先授权、脱敏、加密、限权、短期保留，并支持审计和删除。

Q7：供应商模型升级怎么控制风险？​

答案：记录精确版本，订阅变更通知，对别名更新自动跑评测和灰度，并准备旧版本或替代 Provider 的回滚方案。

Q8：AI 事故的第一步是什么？​

答案：先遏制影响，例如关闭特定工具、数据源、模型或租户功能；随后评估范围、保留必要证据并按流程升级通知。

Q9：引用来源是否足以证明答案可信？​

答案：不足。还要验证引用是否真的支持结论、用户是否有权访问、内容是否最新以及引用是否被模型曲解。

Q10：如何避免治理拖慢所有实验？​

答案：按风险分级提供预批准模板、安全沙箱、标准网关和自动评测。低风险快速通道与高风险严格门禁可以同时存在。

Q11：谁对 AI 结果负责？​

答案：最终由部署和使用该系统的组织及具体业务 Owner 按职责负责；模型或供应商不能成为模糊责任的替代物。

Q12：NIST AI RMF 的四个核心动作是什么？​

答案：Govern、Map、Measure、Manage。它们不是一次性线性步骤，而是在系统生命周期中持续迭代的风险管理闭环。

参考资料​

相关阅读​