什么是 AI 治理?它是一个组织为确保其 AI 系统安全、合法、合乎道德且与业务目标保持一致地运行而建立的政策、问责结构、技术控制和监督机制的结构化组合。没有它,AI 的采用会比创造价值更快地创造风险。

什么是 AI 治理这个问题对不同组织在不同时刻出现。一些组织是在合规审计揭示了 AI 工具在业务中使用方式的差距后才面对这个问题。其他组织是在 AI 生成的错误到达客户或监管机构,而没有人能清楚解释谁对产生该错误的系统负责之后才面对这个问题。最聪明的组织在这两种情况发生之前就提出这个问题,认识到防止事件发生的治理纪律同时也为自信、可扩展的 AI 采用创造了条件。治理不是减慢 AI 部署的摩擦。它是使 AI 部署在规模化、受监管行业以及在出错的后果超出眼前任务、延伸到组织的法律地位、客户关系和长期竞争地位的情境中可持续的基础。本指南解释了 AI 治理涵盖什么,它如何构建,以及在 AI 成熟度的每个阶段的组织需要构建什么。

为什么 AI 治理已成为业务必需

未受治理的 AI 创造的问责缺口

在业务背景下,每个做出或为决策提供信息的 AI 系统都会产生问责问题。如果决策是错误的,谁负责?如果系统产生有害的输出,谁承担这种损害?如果监管机构询问某个特定结果是如何得出的,谁能解释它并出具支持该解释的文档?

在没有 AI 治理框架的组织中,这些问题始终产生相同的答案:没有人明确负责,文档不存在,无法提供解释。这种答案在监管调查、诉讼以及大规模 AI 失败之后的客户和声誉后果中代价昂贵。

AI 治理通过在 AI 系统部署之前定义每个系统的所有者、该所有权在持续责任方面意味着什么,以及哪些文档和监督实践创造问责所需的审计追踪,从而填补问责缺口。它将未受治理的 AI 的隐性、分散的问责转变为明确的、可执行的责任,使组织能够在被询问时回答困难的问题。

治理的业务理由不仅仅是降低风险。具有成熟 AI 治理框架的组织在新的 AI 部署上行动更快,因为评估流程、合同模板和每个新部署的监督结构已经存在。受治理的组织中的第一个 AI 部署构建了使每个后续部署更快、更安全的基础设施。未受治理的组织中的第一个部署与第五个一样缓慢和有风险,因为没有任何东西被传承下来。

加速治理采用的监管压力

在监管期望的背景下,什么是 AI 治理?它越来越多地是金融服务、医疗保健、数据保护以及 AI 特定监管框架中的监管机构直接提出的直接问题的答案。EU AI Act 对部署高风险 AI 系统的组织施加治理义务。金融监管机构已将 AI 治理纳入审查框架。数据保护当局期望大规模通过 AI 处理个人数据的组织作为 GDPR 合规的一部分有书面化的 AI 治理。

监管轨迹在各个司法管辖区都是清晰和一致的。对书面化 AI 治理的期望正在收紧,而不是放松,响应当前要求构建治理项目的组织正在领先于正在发展中的要求,而不是落后于已经强制执行的要求。

了解 AI security 要求如何与更广泛的 AI 治理框架相互作用,有助于组织构建安全控制和治理结构相互加强的项目,而不是作为并行、脱节的努力运作,从而在它们的边界处产生缺口。

AI 治理的八项原则

大多数成熟的 AI 治理框架,无论是由领先组织内部开发的还是由监管和标准机构编纂的,都围绕一组一致的基础原则进行组织。理解这些原则提供了使具体治理政策连贯而非任意的概念架构。

透明度要求 AI 系统及其决策流程对其影响的人员和负责它们的组织是可理解的。透明度并不意味着每个模型的每个技术细节都公开披露。它意味着 AI 在决策中参与的存在、做出这些决策的一般依据以及围绕系统的问责结构对那些有合法兴趣理解它们的人是可知的。

问责制要求一个有姓名的人或组织实体对每个 AI 系统的运行、其输出和后果负责。缺乏明确的问责制是大多数 AI 治理失败的根本原因,而明确地建立它是其他控制措施从中流出的基础治理行为。

公平性要求 AI 系统不会产生系统性地使受保护群体处于不利地位或以不公正方式延续历史偏见的输出。对于业务 AI 系统,公平性在大多数司法管辖区既是道德义务又是法律义务,特别是对于用于就业、信贷、住房和类似高风险决策情境的 AI。

安全性和可靠性要求 AI 系统始终如一地执行其预定功能,并且故障通过定义的流程被检测、控制和解决,而不是通过影响被发现。

隐私要求 AI 系统按照适用的数据保护法和对其数据被处理的个人的合理期望来处理个人数据。

安全要求 AI 系统受到保护,免受 AI 系统面临的特定攻击向量和故障模式的影响,包括提示注入、数据泄露和对抗性操纵。

人工监督要求结果性 AI 决策受到有意义的人工审查,而不是完全委托给没有问责制的自动化系统。

合规要求 AI 系统在适用于其部署情境的法律和监管框架内运行,包括行业特定法规、数据保护法和新兴的 AI 特定监管要求。

实践中 AI 治理的四大支柱

理解什么是运营层面的 AI 治理需要从原则转向在组织实践中实施这些原则的结构性组件。四大支柱提供了构建大多数有效 AI 治理项目的结构性框架。

支柱一:政策和标准

AI 治理的政策层定义了贵组织关于可接受的 AI 使用、禁止的 AI 应用、AI 系统的数据处理要求,以及 AI 部署在投入生产之前必须满足的标准的决定。这些是为员工、供应商和监管机构提供贵组织要求的书面参考点的书面化决定。

有效的 AI 治理政策具体到足以指导真实决策,而不会粒度过细以至于在墨水干燥之前就过时。规定 AI 工具在没有签署数据处理协议的情况下不得处理个人身份信息的政策是具体、持久和可操作的。逐个列出每个批准的 AI 工具的政策每次采用新工具或停用现有工具时都会过时。

最重要的早期建立的政策是定义员工如何能够和不能够使用 AI 工具的 AI 可接受使用政策、将数据敏感性类别映射到允许的 AI 处理环境的数据分类政策,以及定义工具在组织数据可以流经它们之前必须满足的安全和合规要求的 AI 采购政策。

政策类型	它定义了什么	它主要管辖谁
可接受使用	员工允许和禁止使用的 AI 工具	所有员工
数据分类	哪些数据类别可以通过哪些 AI 系统处理	所有员工和 AI 系统操作员
采购和供应商	AI 工具的安全和合规要求	采购、IT、法务
开发和部署	AI 系统在生产发布前必须满足的标准	工程和产品团队
事件响应	如何检测和处理 AI 安全和质量故障	安全和运营团队
模型风险管理	受监管活动中 AI 模型的验证、监控和治理	风险和合规职能

支柱二:问责制和所有权结构

问责支柱定义了在整个 AI 治理项目和每个单独的 AI 系统中谁对什么负责。没有明确的所有权,政策就是没有执行的文件,事件就是没有所有者的事件。

AI 治理的问责通常在两个层面运作。项目层面建立谁拥有整体的 AI 治理框架,通常是首席 AI 官、首席风险官或具有来自法务、安全、合规和业务领导层的跨职能代表的 AI 治理委员会。这种项目层面的所有权设定标准、审查其充分性,并在整个 AI 部署足迹中保持可见性。

系统层面为每个单独的 AI 系统分配一个有姓名的所有者,该所有者负责该系统对治理标准的合规性、其安全态势、其输出的质量,以及在出现问题时的适当响应。这个所有者不一定是技术专家。他们是负责的人员,确保系统在治理要求内运行,并拥有关于该系统何时需要修改、限制或退役的决策。

审查 AI architecture 决策如何影响系统所有权的清晰度以及系统所有者履行其治理职责的实际能力,有助于组织设计部署,使问责制不仅在书面上分配,而且在操作上有意义。

支柱三:风险评估和管理

风险管理支柱涵盖组织如何在特定 AI 部署上线之前以及在其整个运营生命周期中持续地系统识别、评估和应对与之相关的风险。

AI 系统的风险评估需要解决表征 AI 特定风险的四个主要风险类别。运营风险涵盖 AI 系统可能失败或性能下降的方式。数据风险涵盖在 AI 系统运营过程中如何处理组织数据和个人数据。合规风险涵盖部署触发的监管和法律义务。声誉风险涵盖 AI 故障损害组织与客户、合作伙伴和监管机构关系和地位的可能性。

GDPR 要求对高风险 AI 处理进行的数据保护影响评估为更广泛的 AI 风险评估提供了有用的模板,即使对欧盟以外的组织和超出隐私范围的风险也是如此。其记录系统做什么、它处理什么数据、它创造什么风险以及哪些缓解措施应对这些风险的结构很好地转化为 AI 治理风险评估需求的完整范围。

支柱四:监控、审计和持续改进

监控支柱涵盖组织如何持续了解其 AI 系统是否在治理要求内运行,如何检测偏差,以及如何使用该运营经验来改进单个系统和治理项目本身。

AI 治理目的的监控超出了运营团队处理的技术性能监控。它包括定期审查 AI 系统输出的质量和偏见、对访问日志的适当使用模式进行审计、审查供应商对合同义务的遵守情况,以及评估随着 AI 部署环境和监管环境的演变,治理政策是否仍然充分。

这一支柱的持续改进维度是将成熟的 AI 治理项目与合规演练区分开来的。基于运营经验更新其政策、完善其风险评估框架并加强其控制措施的项目随着时间推移在有效性上复合增长。在某个时间点建立治理并将其视为已完成的项目会累积其书面化标准与其治理的实际 AI 环境之间日益增长的差距。

了解企业 AI 平台中的 AI features 如何支持治理监控、审计日志记录和合规报告,有助于组织选择其运营特性支持而非破坏其治理项目要求的工具。

实践中 AI 治理的样子

跨部署生命周期的实际示例

一家金融服务公司部署 AI 系统以协助关系经理与客户沟通,说明了 AI 治理在完整部署生命周期中的样子,而不是作为一个抽象框架。

部署之前,治理项目要求进行风险评估,记录系统处理什么数据、适用什么监管要求、需要什么安全控制以及系统所有者将是谁。采购流程验证供应商持有适当的认证、将签署所需的数据协议,并且不使用客户数据进行模型训练。为所涉及的个人数据处理完成数据保护影响评估。对系统进行输出质量、跨客户细分的推荐偏见以及对提示操纵的安全性测试。

在部署期间,系统所有者通过定期抽样监控输出质量、审查升级模式以评估授权边界是否正确校准,并维护公司合规职能和潜在监管审查所需的审计日志文档。安全团队监控访问模式中的异常情况,并定期测试自初始安全评估以来可能出现的新提示注入技术。

每年,治理审查评估风险评估是否仍然当前、供应商认证是否仍然有效、政策框架是否充分涵盖了系统的演变,以及监控方法是否产生了维持治理信心所需的可见性。系统、其连接性或监管环境的变化会触发新的评估,而不是等待年度周期。

这种生命周期方法是将治理与合规作秀分开的原因。每个阶段都有定义的行动、定义的所有者和定义的文档,共同产生一个真正受治理的系统,而不仅仅是被描述为受治理的。

AI 治理所需的技能

构建和运营有效的 AI 治理项目所需的专业能力跨越几个学科,这些学科很少在单独的从业者中共存,这就是为什么 AI 治理职能往往是跨职能的,而不是位于单一团队中。

对 AI 系统的技术理解,足以评估风险、评估安全控制并与工程团队就治理要求进行有意义的沟通,这是基础。这不需要机器学习研究专业知识,但确实需要足够的实践 AI 素养来区分有意义的安全主张和营销语言,并理解架构决策如何影响治理结果。

涵盖数据保护法、行业特定法规和新兴的 AI 特定监管环境的法律和监管专业知识对于构建满足适用于组织 AI 部署的合规义务的治理项目至关重要。

风险管理方法论,包括用于系统识别、评估、记录和管理组织风险的框架和实践,直接转化为 AI 治理风险评估工作,并提供了临时治理工作通常缺乏的结构化方法。

政策制定和组织变革技能决定了治理项目是产生改变行为的文档还是没有人阅读的文档。将技术和法律要求翻译成员工可以遵循且领导层将执行的清晰、实用的政策的能力是单凭技术和法律专业知识无法替代的治理能力。

连接技术、法律和业务受众的沟通技能是有效 AI 治理的结缔组织。无法将其要求清楚地传达给工程师、将其合规证据清楚地传达给监管机构以及将其风险评估清楚地传达给执行领导层的治理项目,无论其技术质量如何,都会在使其有效的组织整合中失败。

需要了解的事项

关于实践中 AI 治理是什么的几个重要现实,组织在项目发展过程中持续遇到:

治理需要在事件之前存在,而不是作为对事件的响应。主动构建 AI 治理的组织将其作为一种能力来发展。在事件之后被动构建治理的组织是在时间压力下构建的,利益相关者的信心已经受损,而且通常更缺乏灵活性来设计他们真正需要的项目,而不是眼前事件所要求的项目。

AI 治理的范围需要包括嵌入式 AI,而不仅仅是独立的 AI 工具。嵌入在广泛使用的企业软件、生产力应用和通信平台中的 AI 功能在通常比独立的 AI 工具部署不太可见、不太仔细评估的治理条件下处理组织数据。范围仅限于显而易见的 AI 工具的治理项目存在显著的盲点。

治理文档同时服务于多个目的。一个构建良好的 AI 风险评估同时满足监管审查要求、指导系统所有者决策、为安全测试优先级提供信息,并支持与供应商的采购谈判。设计治理文档以服务于其多个受众,与为每个目的创建单独的工件相比,减少了总文档负担。

30% 原则适用于治理流程设计。AI 治理项目运营应依靠自动化监控、系统化日志记录和结构化审查流程来处理大约 30% 的治理活动,特别是高频率、基于规则的监控工作,而治理专业人员将其专业知识集中在涉及风险判断、监管解释、事件响应和需要人类问责的战略治理决策的 70% 上。

董事会层面对 AI 治理的参与正在成为许多行业的监管期望。金融机构、医疗机构和上市公司的董事会越来越被期望展示对 AI 风险的积极监督,而不仅仅是意识到 AI 治理项目的存在。构建为董事会消费而设计的治理报告是一种项目成熟度能力,在大多数组织预期需要它之前就变得重要。

AI 治理项目需要与它们治理的 AI 系统一样的版本控制和变更管理。随着监管环境的变化、组织 AI 足迹的演变和威胁环境的发展,治理政策和程序需要以书面化、受控的方式更新,以维持项目在每个时间点要求的可审计历史。

将 AI 治理构建为战略性组织能力

在最具战略性的层面上,什么是 AI 治理?它是决定企业是否能够自信地、可持续地采用 AI,还是必须在快速行动和管理风险之间做出选择的组织能力,因为它尚未构建允许同时做到这两点的基础。

发展强大 AI 治理的组织始终发现,它使他们的 AI 雄心成为可能而不是受到限制。治理所需的批准工具项目、供应商评估流程、风险框架和监控基础设施都减少了每个系统从 AI 想法到安全生产部署的时间,在第一个系统之后。第一次部署构建了基础。每个后续部署都受益于此。

一份关于从初始框架开发到组织成熟构建 AI 治理项目的全面 AI guide,帮助组织构建其治理投资,以获得成熟项目所提供的复合回报,而不是不成熟方法所产生的一次性合规演练。

监管环境、竞争格局以及围绕 AI 的组织利害关系都朝着同一方向发展。将 AI 治理作为一种真正能力构建的组织,具有能力发展所需的投资、人才和领导承诺,正在一个无法负责任地治理其 AI 的组织发现其无法这样做成为对他们可以部署什么、可以在哪里运营以及谁会信任他们的数据和决策的约束性限制的环境中,构建一个可持续的竞争地位。

常见问题

AI 治理的一个例子是什么?

AI 治理的一个实际例子是一家金融服务公司,要求每个 AI 系统在部署前完成书面化的风险评估、分配一个有姓名的系统所有者负责持续的合规监控、维护所有 AI 辅助决策的审计日志以供监管审查,并对照当前政策标准和监管要求对每个系统进行年度审查。 这个例子说明了治理是一种完整的生命周期实践,而不是一次性的批准流程,涵盖了将真正的治理与合规作秀区分开来的问责制、文档和持续监督。

AI 治理需要什么技能?

AI 治理所需的核心技能是足以评估风险和评估安全控制的技术 AI 素养、涵盖数据保护和行业特定 AI 义务的法律和监管专业知识、用于系统评估和文档的风险管理方法论、将要求转化为实用组织指导的政策制定能力,以及连接技术、法律和业务领导层受众的跨职能沟通技能。 由于这些技能很少在单独的从业者中共存,有效的 AI 治理职能通常是跨职能团队,而不是单一学科的角色。

AI 治理的 8 项原则是什么?

AI 治理的八项原则是关于 AI 系统存在和决策逻辑的透明度、通过明确的 AI 系统及其后果的人类所有权实现问责制、确保 AI 输出不会系统性地使受保护群体处于不利地位的公平性、通过一致的性能和定义的故障管理实现的安全性和可靠性、保护 AI 系统处理的个人数据的隐私、防御 AI 特定攻击向量和故障模式的安全、对结果性 AI 决策保持有意义的人工审查的人类监督,以及符合适用于每个部署情境的法律和监管框架的合规性。 这些原则提供了使具体治理政策连贯的概念架构,使组织能够评估其治理项目是否在解决负责任的 AI 部署所需的全部义务范围。

AI 治理的四大支柱是什么?

AI 治理的四大支柱是定义 AI 部署和使用的组织要求的政策和标准、为每个 AI 系统分配明确的人类责任的问责制和所有权结构、在部署前和部署期间系统识别和应对 AI 特定风险的风险评估和管理流程,以及保持对治理合规性持续可见性并推动项目长期发展的监控、审计和持续改进实践。 这些支柱共同创造了将 AI 治理原则转变为运营实践的结构性框架,为组织提供了既能设定标准又能验证这些标准在其整个 AI 部署足迹中得到满足的机制。

哪 3 种工作将在 AI 中幸存?

最能抵御 AI 替代的三类工作是需要复杂人类判断和对结果性决策的伦理问责的角色、建立在人际信任、关系管理和 AI 无法复制的情感智能之上的角色,以及涉及物理世界专业知识和 AI 系统尚不能可靠导航的非结构化环境中的灵巧性的角色。 AI 治理本身代表了一个不断发展的专业领域,结合了几个这些有韧性的特征,需要使其真正抵抗它旨在监督的自动化的人类判断、监管解释、组织沟通和问责结构。