AI治理：模型、数据、权限、风险与可审计性

AI 治理是一套由决策权、职责、控制措施和证据构成的体系，用于决定组织可以如何开发、获取、部署、运营、变更和退役 AI 系统。它比一份政策文件更广泛，但又比整体企业架构更狭窄。有效的 AI 治理将业务所有权、模型与供应商选择、数据权限、许可、风险分类、评估、监控、事件处理、可审计性和生命周期决策连接起来，使人们不仅能够回答“AI 是否有效？”，还能够回答“谁批准了它、在什么条件下批准、依据什么证据，以及该决策何时必须重新审视？”

AI 治理的真正含义

AI 治理回答的是模型、SDK 或架构图本身无法回答的组织问题。谁拥有业务成果？谁可以批准新的供应商？哪些数据类别被禁止进行外部处理？部署前需要哪些证据？智能体可以获得哪些权限？谁可以接受剩余风险？当模型在升级后行为发生变化时会发生什么？

其目的不是阻止变化。良好的治理使变化清晰可辨：决策有负责人、证据、条件、例外、复审日期以及回滚或升级路径。

这就是为什么 NIST 将 GOVERN 置于整个 AI 风险管理生命周期之中，而不是将治理视为最后一个审批步骤。治理确立了文化、政策、问责制和组织结构，使映射、衡量和管理 AI 风险成为可能。

最简单的例子

一个产品团队希望添加一个外部生成式 AI 供应商，用于总结内部客户支持工单。从技术上讲，集成可能只需要一次 API 调用。

治理会提出另一组问题：工单内容是否被允许离开组织环境？批准了哪个供应商和模型版本？是否禁用了保留？哪些用户可以调用该功能？如何评估输出？是否需要人工审核？记录哪些内容？谁负责事件？如果供应商更改条款或模型行为会发生什么？

治理结果可能仍然是“部署它”。区别在于，部署现在是一个具有明确条件、可追踪的决策，而不是一项未被记录的工程选择。

一个基本的受治理 AI 决策

1

1. 登记用例

记录目的、负责人、用户、数据、模型/供应商以及预期成果。

2

2. 对风险和义务进行分类

确定业务后果、数据敏感性、自主性、监管暴露和滥用可能性。

3

3. 定义所需控制措施

明确权限、数据处理、评估、人工监督、安全、日志记录和供应商约束。

4

4. 收集证据

运行测试、安全/隐私审查、架构审查以及相关法律/合规检查。

5

5. 做出决策

批准、有条件批准、要求修改、暂缓或拒绝。

6

6. 在受控配置下部署

固定已批准的模型/供应商/运行时，并强制执行所需边界。

7

7. 监控并重新评估

跟踪事件、质量、漂移、供应商变更、新风险和法规变化。

8

8. 变更、暂停或退役

使用证据和所有权规则来决定下一个生命周期状态。

简单例子止步之处

大型组织很少孤立地治理一个 AI 系统。同一个模型可能支持数十个产品；同一个供应商可能处理多个数据类别；一个智能体平台可能向许多团队暴露共享工具。

因此，治理既需要系统级控制，也需要组合级结构：AI 清单、已批准供应商、模型目录、共享评估基线、安全模式、风险阈值、例外登记册和所有权映射。

治理也不可能对每一种 AI 用途都完全相同。公共内容摘要器、内部编码助手、招聘支持系统以及能够发起支付的智能体，在后果和控制配置上存在实质性差异。

什么是AI治理——以及它不是什么

AI治理与相邻学科的对比

	AI治理	相邻学科
企业/解决方案架构
AI风险管理
合规
安全
MLOps / LLMOps
AI伦理原则

治理的范围比合规更广

合规是治理的一项输入，而非整个治理体系。一个AI用例可以合法被允许，但仍可能违反公司风险偏好、安全政策、合同义务或产品质量要求。

反过来也同样重要：内部批准不能凌驾于法律之上。治理应使适用的法律义务在用于架构、安全和业务风险的同一决策路径中可见。

ISO/IEC 42001明确将AI管理体系界定为一种结构化方式，用于建立负责任AI的政策、目标和流程。ISO还指出，该标准不替代法律或法规；它提供了一个可支持合规的管理框架。

NIST AI RMF和ISO/IEC 42001解决不同的治理需求

这些来源不应被合并为一份检查清单。NIST AI RMF是风险管理指南。ISO/IEC 42001是管理体系标准。EU AI Act是法律。组织可以将它们一起使用，但它们的权威性、范围和实施目的各不相同。

当前EU AI Act的时间安排很重要

截至2026年10月8日，欧盟委员会表示AI Act于2026年8月2日普遍适用。禁止性做法和AI素养条款自2025年2月2日起适用，而通用AI模型的治理规则和义务自2025年8月2日起适用。

委员会当前的指南还反映了某些高风险要求的较晚适用日期。确切的日期和过渡规则是不断变化的合规输入，在做出部署决定前应依据委员会当前材料进行核实。

AI治理从清单开始

组织无法治理其无法识别的AI系统。清单应涵盖的不仅仅是自定义训练的模型。它可能包括外部模型API、嵌入式copilot、本地模型、支持AI的SaaS功能、代理运行时、检索系统和自动化决策组件。

有用的清单将AI能力与其业务负责人、技术负责人、用例、用户、数据类别、模型/提供者、部署环境、权限、风险分类、评估状态、适用义务和生命周期状态联系起来。

清单不仅仅是给审计人员看的电子表格。它是索引，让组织知道当提供者变更、漏洞出现、法规变得适用或模型退役时必须审查什么。

治理需要明确的责任归属

AI 故障往往跨越组织边界。模型质量问题可能演变为产品故障、安全问题、隐私事件或合同违约。治理需要在事件发生之前就明确责任人。

责任归属并不意味着一个人对所有事情负责。一个健全的模型会分离决策权：业务负责人、产品负责人、技术负责人、数据负责人、安全/隐私专家、法律/合规角色和运营支持。

关键特性是每项必需的决策都有负责人，并且每位负责人都知道他们需要审查哪些证据。

决策权应当明确

模型治理不仅仅是选择模型

模型治理跟踪使用哪个模型、用于什么目的、在何种配置和证据下。这适用于外部 API、本地托管模型、微调模型以及嵌入第三方软件中的模型。

模型决策应考虑能力、评估结果、成本、延迟、数据处理、提供商条款、生命周期支持、地理/托管限制、安全性、回退行为以及版本变更的后果。

诸如“latest”之类的模型别名在操作上可能很方便，但如果行为在没有受治理的发布流程下发生变化，则会削弱可复现性。有重大后果的系统受益于明确的版本跟踪和回归评估。

提供商治理是一个独立的依赖层

使用同一模型系列的两个系统可能具有不同的治理风险，如果一个在本地运行，另一个将数据发送给外部提供商。提供商治理涵盖合同条款、处理位置、保留、日志记录、子处理者、可用性、弃用和退出策略。

提供商抽象可以减少技术锁定，但并不能消除治理工作。更换提供商可能会改变数据流、模型行为、安全假设、成本和合规义务。

因此，已批准的提供商列表不应被解释为“来自此提供商的每个模型和每个数据类别都自动获得批准”。批准需要范围。

数据治理仍然是事实来源层

AI 治理并不会使模型成为组织事实的权威。数据治理仍然决定源数据的所有权、分类、保留、质量和允许使用。

对于 RAG 和代理，治理应确定哪些来源是权威的、哪些是建议性的、如何保留来源、哪些数据可以进入模型上下文以及必须强制执行哪些租户/用户边界。

生成的输出也会产生新的数据治理问题：提示和响应是否保留、谁可以访问跟踪、生成的摘要是否成为记录，以及当源数据被删除时如何删除派生的嵌入或索引。

权限是治理决策，并在运行时强制执行

代理式人工智能使权限成为一等治理对象。组织需要决定每个代理或用户可以访问哪些工具、文件、API、数据库和副作用。

治理定义策略和审批逻辑；可信运行时执行它。诸如“不要删除文件”之类的自然语言指令不能替代文件系统、API 或服务授权。

同样的原则适用于租户隔离：角色可以授权某项操作，而租户范围限制该操作可以触及哪个客户的资源。

风险分类应改变控制集

并非每个 AI 系统都需要相同的审查深度。当风险分类改变证据、审批和监控要求时，治理就变得可扩展。

分类方法可以简单或复杂，但应映射到具体后果：更多测试、更窄的权限、所需的人工监督、安全审查、高管风险接受或部署禁止。

治理必须保留用例上下文

NIST 的 MAP 功能强调预期目的、用户、部署上下文、假设、影响以及适用的法律或规范。这很重要，因为同一个模型在一个用例中可能是低风险，而在另一个用例中可能产生高后果。

因此，治理记录应对应用进行分类，而不仅仅是模型。“我们使用模型 X”不足以确定风险。

相关的治理对象是系统/用例：模型 + 数据 + 上下文 + 工具 + 用户 + 部署环境 + 业务流程。

评估是治理证据

AI 治理流程不应仅基于供应商基准或成功的演示来批准部署。系统需要与其实际预期用途相关的证据。

有用的证据可以包括任务成功评估、检索质量、事实依据、安全测试、权限测试、对抗性场景、人工审查研究、延迟/成本、鲁棒性和回归比较。

NIST 的 MEASURE 功能明确说明了这一点：组织应识别并应用适当的方法和指标来应对映射期间识别的风险，同时记录无法或不会测量的风险。

治理关口应贯穿整个生命周期

示例生命周期关卡

1

创意/发现关卡

确认业务目的、负责人以及AI是否为合适的解决方案。

2

架构关卡

审查模型/提供商、数据流、身份、权限、隔离和运营设计。

3

风险/合规关卡

对风险进行分类并确定适用义务；定义所需控制措施。

4

验证关卡

要求提供功能、安全、安保和质量标准均已满足的证据。

5

部署关卡

批准具体配置、版本、环境和运营负责人。

6

变更关卡

根据重要性重新评估模型/提供商/工具/数据变更。

7

事件关卡

当定义的风险触发条件出现时，暂停、限制或回滚。

8

退役关卡

干净地移除访问权限、数据衍生品、凭据和过时依赖项。

变更管理是AI治理的核心

即使应用程序代码没有变化，AI系统也会发生变化。提供商会更新模型、安全过滤器、上下文限制、定价、政策和基础设施。检索语料库会变化。代理工具会获得权限。法规和合同也在演变。

因此，治理应定义重大变更触发条件。轻微的提示词措辞调整可能只需要常规回归测试；更换模型、启用写入工具或引入敏感数据可能需要新的审批关卡。

治理记录应保留哪个版本获得了批准，以及哪些条件使该批准有效。

例外需要负责人、到期时间和补偿性控制措施

现实组织需要例外。团队可能需要使用未经批准的模型进行有时间限制的实验，或者遗留系统可能尚未满足新的日志记录要求。

危险的模式是永久性的未记录例外。可治理的例外应明确负责人、理由、范围、剩余风险、补偿性控制措施、到期日期和审查条件。

例外处理应成为正常治理系统的一部分，而不是非正式的旁路渠道。

可审计性是重建决策和执行的能力

AI可审计性不仅仅是存储模型提示词。它意味着能够重建使用了哪个系统版本、应用了哪些数据和权限、谁批准了配置、哪些评估支持了部署，以及相关执行期间发生了什么。

对于代理，这可能要求主体身份、工具调用、审批、目标资源、状态变更和结果。对于RAG，这可能要求语料库/索引版本、检索查询、选定的证据和来源。对于模型变更，这可能要求之前和新的评估结果。

审计证据应适度。记录每一个可能的令牌本身可能会带来隐私和安全风险。治理应定义哪些证据是必要的、保留多长时间以及谁可以访问。

监控闭合治理循环

批准是一个快照。生产监控告诉治理层批准背后的假设是否仍然成立。

有用的信号取决于用例：质量回归、不安全输出、工具故障、策略拒绝、异常成本、延迟、用户投诉、漂移、检索新鲜度、提供商事件、安全警报或新的监管分类。

治理应定义触发行动的阈值：调查、限制、要求人工审查、回滚、切换提供商、暂停或退役。

AI事件需要明确的操作路径

AI特定事件可能涉及有害内容、数据泄露、未授权操作、持续的事实性失败、模型/提供商中断、提示注入、跨租户检索或模型更新后的意外行为。

事件流程应将技术响应与治理责任联系起来。必须有人被授权禁用模型、移除工具、撤销凭证、限制用户、通知受影响的职能部门，并决定系统是否可以恢复服务。

事件中的经验教训应更新政策、测试、风险分类和可复用的平台控制措施，而不是仅停留在某个团队内部。

采购是AI治理的一部分

组织可以通过普通的SaaS采购获得大量AI能力。因此，治理应覆盖购买的AI功能以及内部工程化系统。

供应商审查可以包括数据使用、保留、模型训练政策、子处理者、安全性、事件通知、导出/删除、地理处理、版本变更、服务连续性和合同退出。

技术架构审查和采购审查应共享同一系统清单，以免商业批准偏离实际部署的数据流。

人工监督应被设计，而不仅仅是声明

“人在回路中”只有在人拥有权限、时间、信息和可用的干预机制时才有意义。

如果审查者只看到AI建议，而看不到其证据、不确定性或来源状态，可能只是对输出进行橡皮图章式批准。治理应明确审查者可以检查什么，以及有哪些可用操作：批准、拒绝、编辑、升级或停止。

人工监督还应基于风险。低后果系统可以使用抽样或事后审查，而高后果副作用可能需要在执行前获得批准。

平台治理和用例治理是不同的

两个治理层级

	共享AI平台	单个AI用例
主要关注点
典型批准
证据
治理失败

因此，平台批准应减少重复工作，而不是消除用例责任。“模型已获批准”不同于“该模型在此处的应用已获批准”。

AI治理与企业AI架构

企业AI架构描述了AI系统、平台、数据、身份、提供商、运营和组织系统如何协同工作。AI治理描述了决定这些架构可以如何创建和变更的决策与控制系统。

两者紧密耦合。没有架构的治理可能变成抽象政策。没有治理的架构可能产生技术上优雅但所有权不明确、提供商采用不受控制或风险未经审查的系统。

最强的设计是双向的：治理要求成为架构控制，而架构则揭示治理必须拥有的真实决策。

原始项目证据

Enterprise Aaasaasa 0.1：作为交付结构的治理

Enterprise Aaasaasa 0.1 为需求、架构、原型、验证和项目收尾使用了定义的里程碑。该结构说明了一个核心治理原则：生命周期转换应具有明确的输出和决策点，而不是非正式的“先构建，后审查”流程。

该项目还跟踪范围蔓延、架构延迟和 AI/GDPR 问题等风险，并识别利益相关者群体，包括赞助、指导、架构、安全、营销、外部 API 和托管。

这不构成 ISO/IEC 42001 管理体系。它是更狭义的项目证据，展示了所有权、风险、里程碑和验证如何整合到技术交付中。

SenseFlow：需求和决策可追溯性

SenseFlow 使用从产品目标和用户需求，经过史诗、用户故事、验收标准、架构、实现和验证的结构化路径。决策记录保留决策、理由、替代方案、权衡、状态和日期/版本。

这种可追溯性模式与治理直接相关，因为 AI 控制应连接到证明其合理性的需求或风险。当从业务需求到架构决策再到验证证据的链条可以被重建时，治理体系会变得更强大。

Aaasaasa AI Client：权限和运行时作为受治理的配置

Aaasaasa AI Client 将提供商、模型、运行时位置和权限分开，而不是将它们视为一个“AI 设置”。中央工作区权限配置文件管理工具访问，Direct Chat 没有文件系统/shell 工具，具备代理能力的运行时在明确的权限配置文件下运行。

这种分离展示了一个重要的治理模式：模型选择和行动权限应是独立的配置对象。更强的模型不会自动获得更广泛的文件系统、shell 或业务权限。

实现证据是架构性的，并非声称该应用程序构成经认证的组织 AI 治理体系。

常见 AI 治理失败模式

中央治理并不意味着集中每一个决策

成熟的组织可以集中管理策略、控制模式和升级机制，同时将低风险决策委托给产品或平台团队。

这种联邦式模型比要求中央委员会批准每一次提示变更更具扩展性。中央职能定义风险层级、强制性控制、提供商政策、例外授权和审计要求；团队在这些边界内自主运作。

设计目标是实现一致的问责制，而非最大程度的集中化。

治理治理系统本身

治理需要反馈。否则控制措施可能变成昂贵且无法降低风险的仪式。

治理指标不应奖励文书工作量。有用的衡量标准是决策质量、可追溯性、风险检测和安全交付是否得到改善。

实用的AI治理实施顺序

从可见性到控制构建治理

1

1. 定义治理范围

确定哪些内部构建、采购、嵌入和实验性AI系统被覆盖。

2

2. 创建AI清单

记录所有者、用例、模型/提供商、数据、工具、用户、生命周期状态和风险类别。

3

3. 定义决策权

明确谁可以批准提供商、数据使用、风险接受、例外、部署和退役。

4

4. 建立风险层级

将后果和暴露映射到不同的控制要求。

5

5. 定义可复用的最低控制

为身份、权限、数据、安全、评估、日志记录和人工监督设定基线要求。

6

6. 将治理与架构连接

将策略转化为平台/运行时控制，使团队无法意外绕过。

7

7. 构建基于证据的关卡

在生命周期转换前要求相关的评估、安全、隐私、架构和合规证据。

8

8. 治理模型/提供商变更

通过回归证据跟踪版本、弃用和重大变更。

9

9. 添加监控和事故触发条件

定义哪些生产信号强制进行调查、限制或暂停。

10

10. 形式化例外

要求范围、所有者、剩余风险、补偿控制和到期时间。

11

11. 审计决策与执行

保留将所有者、配置、权限、评估和重大操作关联起来的适当证据。

12

12. 改进治理系统

利用事故、延迟和重复例外来修订控制和平台模式。

AI治理检查清单

常见误解

边缘情况和局限性

非常小的组织可能不需要专门的AI治理职能。相同的原则可以通过轻量级架构决策、风险登记册、所有者映射和发布关卡来实施。

高度受监管的组织可能需要比这篇架构级文章所描述的更为正式的治理、独立保证、文档化合规流程和法律解释。

开源和自托管模型减少了一些提供商依赖，但产生了其他依赖：补丁、模型来源、评估、基础设施安全、许可和运营所有权。

通用AI模型可以在许多上下文中使用。治理应避免假设提供商级别的模型控制完全决定下游应用风险。

没有任何治理框架能保证AI系统是安全或正确的。治理提升问责性和决策质量；技术验证、监控和人类判断仍然必不可少。

什么会改变这个答案？

具体的控制措施集合会随法律、行业、组织规模、数据敏感性、自主性、部署模式和业务后果而变化。

NIST目前正在修订AI RMF 1.0，因此未来的NIST术语或推荐实践可能会发生变化。ISO标准也可能被修订，而欧盟AI法案的指南和过渡细节也在持续演变。

稳定的架构原则是：AI决策需要明确的负责人、证据、权限、风险处理和生命周期审查，而不是隐藏在模型或应用程序配置中。

相关规范知识

AI治理依赖于本知识图谱中已在其他地方分离的概念：真相来源决定权威性，RBAC和租户隔离约束访问，上下文工程控制模型可见信息，而智能体架构定义工具和行动如何进入执行循环。

企业AI架构是父级组织架构概念。治理是运营控制层，决定这些企业AI组件如何被引入、变更和退役。

智能体系统增加了治理要求，因为模型决策可能产生真实的副作用。因此，权限、审批和审计控制必须存在于模型本身之外。

常见问题

AI治理常见问题

什么是AI治理？

AI治理是用于管理AI系统如何被开发、采购、部署、运营、变更和退役的所有权、决策权、控制和证据体系。

AI治理与AI风险管理相同吗？

不相同。风险管理识别、评估和处理风险。治理定义谁必须做这项工作、哪些决策需要它以及需要什么证据或权限。

AI治理与合规相同吗？

不相同。合规涉及适用的法律、监管、合同或内部义务。治理将合规与架构、安全、数据、质量、权限和业务所有权整合在一起。

AI治理与企业AI架构有什么区别？

企业AI架构定义AI能力和系统如何融入组织。AI治理定义管理这些组件如何被引入、运营和变更的决策与控制体系。

小公司需要AI治理吗？

需要，但不一定需要专门的部门。轻量级的清单、所有权、权限、评估和变更控制可以实现相同的原则。

AI清单应包含什么？

至少包括：用例、负责人、模型/提供商/版本、数据类别、用户、工具/行动、权限、风险分类、评估状态、生命周期状态和审查触发条件。

使用已批准的模型意味着用例已获批准吗？

不。风险取决于应用场景：数据、用户、工具、自主性、后果和业务流程。

什么使AI系统可审计？

组织能够重建相关的所有权、已批准的配置、模型/提供商/版本、数据/权限上下文、评估证据、重要行动和生命周期决策。

AI治理决策应多久审查一次？

使用基于风险的审查间隔加上事件触发条件，例如模型/提供商变更、新数据、新工具、事件、重大性能变化或监管更新。

术语表

关键AI治理术语

AI治理

管理AI生命周期的所有权、决策权、控制和证据的组织体系。

AI管理体系

用于负责任地开发、提供或使用AI的相互关联的组织政策、目标和流程；ISO/IEC 42001规定了此类体系的要求。

AI清单

AI系统、模型、提供商、用例、负责人、数据、风险分类和生命周期状态的登记册。

风险负责人

被指定负责决定如何处理已定义风险或是否接受剩余风险的权威人员。

控制措施

旨在预防、检测、减少或应对风险的技术、组织或程序措施。

治理关口

生命周期决策点，在继续之前需要定义的证据和权限。

剩余风险

在应用控制措施或缓解措施后仍然存在的风险。

例外

明确、有范围且通常有时间限制的授权，允许偏离正常的治理要求。

可审计性

重建相关决策、配置、证据、身份和执行事件的能力。

模型治理

涵盖模型选择、版本管理、评估、允许使用、变更和退役的控制和决策。

提供商治理

涵盖外部或内部AI提供商依赖关系、数据处理、安全、合同、生命周期和退出的控制。

人类监督

在定义的点上为AI决策或行动设计的人类审查或干预能力。

结论

AI治理是围绕AI的组织控制平面。它为那些否则会隐藏在代码、提供商设置、提示词或非正式团队判断中的决策赋予名称和证据。

强有力的治理连接整个系统：业务目的、模型、提供商、数据权限、身份、权限、评估、风险、合规、监控、事件、变更和退役。

实际目标不是最大化流程。而是最小化的治理结构，使重要的AI决策在整个生命周期中拥有明确的责任归属、基于证据、可执行、可审查和可审计。

主要来源和当前参考

以下来源为AI管理、风险和监管提供了当前的外部依据。项目部分是原始的实施/项目证据，并明确区别于正式标准或认证的治理体系。

NIST — AI风险管理框架

NIST当前关于AI RMF 1.0、正在进行的修订、GenAI配置文件及相关风险管理资源的中心。

NIST AIRC — AI RMF核心

官方AI RMF核心描述了治理、映射、测量和管理，其中治理是跨生命周期的职能。

NIST — AI RMF操作手册

在AI生命周期中实施可信度和风险管理的建议行动。

NIST AI 600-1 — 生成式AI配置文件

NIST配套配置文件，将AI RMF概念应用于生成式AI风险和生命周期管理。

ISO/IEC 42001:2023 — AI管理系统

国际标准，规定了建立、实施、维护和持续改进AI管理系统的要求。

ISO/IEC 23894:2023 — AI风险管理

将AI特定风险管理整合到组织活动和职能中的国际指南。

欧盟委员会 — AI法案

欧盟委员会当前关于欧盟AI法案、应用时间表和实施框架的概述。

欧盟委员会 — 导航AI法案

当前常见问题解答，涵盖治理、执法、实施和不断变化的应用时间表。

欧盟委员会 — 通用AI义务

当前关于GPAI提供商的文件、版权、训练内容和系统性风险义务的概述。