建立信任：AI 安全防护、安全性和透明度的基础

本博客改编自红帽的同名研究论文（Bestavros、Chen、Fox、Mollett 和Sidhpurwala，2024 年）。您可以在此处访问全文。

随着公开可用的人工智能（AI）模型的快速发展，潜在的安全防护与安全性的影响也在不断加剧，这就要求我们更深入地了解其风险和漏洞。为了在 AI 模型及其开放生态系统和社区的开发和运维过程中实现标准化安全防护、安全性和透明度，我们必须改变应对当前挑战的方式，例如关于模型的一致信息、缺乏区分安全防护与安全性的问题，以及模型开发商可用的和使用的安全评估不足且不够标准化。

风险和漏洞

AI 安全防护和 AI 安全性虽然相似，但在管理 AI 系统风险方面却截然不同。AI 安全防护侧重于保护系统免受外部和内部威胁，而 AI 安全性则强调确保系统和数据不会因为模型的运行、训练或使用而威胁或损害用户、社会或环境。然而，AI 安全防护和安全性之间的关系通常比较模糊。

通常被视为安全防护问题的攻击可能会导致安全问题（反之亦然），例如产生有毒或有害内容或暴露个人信息的模型。AI 安全防护与安全性的交集凸显了迫切需要一种全面的 AI 风险管理方法，以同时解决安全防护和安全性的问题。

当前的挑战和趋势

尽管 AI 行业已采取措施解决安全防护问题，但仍然存在几个关键挑战，例如速度优先于安全、治理不足和报告实践不足。新兴趋势表明，瞄准这些增长领域对于开发有效的 AI 安全防护、安全性和透明机制的实践至关重要。

速度优先于安全

本着快速开发和部署 AI 技术以“确保”增加市场份额的精神，许多企业将加快产品上市速度置于安全测试和道德考量之上。从过去的安全事件中可以看出，安全防护往往落后于新兴技术数年，通常会在行业开始自我纠正之前发生重大事件。可以合理地预测，如果没有个人推动 AI 风险管理，我们可能会遇到重大且严重的安全事故。虽然新模型的引入考虑到了安全防护和安全性，但由于缺乏关于如何传达必要的安全性和透明度信息的共识，因此很难对其进行评估，尽管具备安全意识的模型增加对于 AI 行业来说是一个积极的进步。

治理和自我监管

由于政府立法很少，人工智能行业一直依赖于自愿的自我监管和不具约束力的道德准则，但事实证明，这不足以解决安全问题。此外，拟议的立法通常与技术行业的现实或行业领导者和社区提出的担忧不符，而企业的 AI 计划可能无法解决结构性问题或提供有意义的问责制，因为这些计划是专为自用而开发的。

自治取得了有限的成功，往往涉及独立于主要功能开发而实施的一组明确的最佳实践。正如各行各业历来所见，以牺牲功能为代价来优先考虑安全防护，往往是利益相关者不愿意做出的权衡。AI 将这一挑战扩展到包括对安全的直接影响，从而使这一问题进一步复杂化。

报告实践不足

就行业目前的现状而言，在处理用户报告的模型缺陷方面缺乏通用的方法和实践。部分原因在于，业内存在缺陷但功能正常的软件漏洞披露和报告系统并不是人工智能报告的同类解决方案。AI 是数据科学和机器学习（ML）的技术演进，与传统的软件工程和技术开发不同，因为它专注于数据和数学，而不是为用户构建系统，而用户已经建立了威胁建模、用户交互和系统方法安全性。如果没有一个易于理解的安全隐患披露和报告系统，直接联系模型制作者来报告问题可能既麻烦又不现实。如果没有一个易于理解的标准化报告流程，由于协调和解决延迟，AI 安全事件的影响可能会远远超出应有的程度。

解决方案和策略

在很大程度上借鉴了 Cattel, Ghosh & Kaffee (2024) 的先前工作，我们相信扩展模型/系统卡和危险跟踪对于改善 AI 行业的安全防护至关重要。

扩展模型/安全卡

模型卡用于记录 AI 模型的可能用途及其架构，偶尔也记录模型所用的训练数据。模型卡目前用于提供一组关于模型的初始人工生成材料，然后用于评估其可行性，但模型卡可能具有超出其当前用途的更多潜力和适用性，无论它们在哪里旅行或在哪里部署。

为了有效地比较模型，采用者和工程师需要卡片上显示一组一致的字段和内容，这可以通过规范来实现。除了Barnes, Gebro, Hutchinson, Mitchell, Raji, Spitzer, Vasserman, Wu & Zaldivar，2019 年推荐的字段外，我们建议进行以下更改和添加：

• 扩展意图和使用来描述模型的用户（谁）和用例（什么），以及如何使用模型。
• 添加范围，以排除模型制作者不打算或没有能力解决的已知问题。这将确保危险报告者在报告根据其定义的用途无法解决的问题之前了解模型的用途。
• 调整评估数据以提供嵌套结构，以传达是否也使用了框架，以及对模型运行的评估输出。通过标准化的安全评估，熟练的用户能够构建可持续的等效模型。
• 添加有关模型的治理信息，以了解采用者或消费者如何与模型制作者互动或了解模型是如何生成的。
• 提供可选的参考信息，如工件和其他内容，以帮助潜在消费者了解模型的运作，并展示给定模型的成熟度和专业性。

通过要求模型卡包含这些字段，行业可以开始建立推理、决策和再现模型所必需的内容。通过为模型卡片制定行业标准，我们将能够促进模型及其元数据在整个生态系统中的互操作性。

危害跟踪

虽然用于跟踪安全缺陷的常见漏洞披露流程在传统软件安全防护中是有效的，但其在 AI 系统中的应用面临着几个挑战。首先，ML 模型问题必须满足统计有效性阈值。这意味着，AI 模型中发现的任何问题（如偏差）都必须根据既定统计标准进行测量和评估，以确保它们有意义且重要。其次，与可信度和偏见相关的担忧通常超出安全漏洞的范围，可能与公认的定义不一致。认识到这些限制后，我们相信通过一个集中、中立的协调危害披露和暴露委员会以及共同缺陷和暴露（CFE）编号来扩展生态系统可以解决这些问题。这与 MITRE 在 1999 年推出的CVE 类似，旨在识别软件和固件中的漏洞并进行分类。

发现安全问题的用户应与模型提供商协调，以进行分类并进一步分析问题。一旦问题被确定为安全隐患，委员会就会分配一个 CFE 编号。模型制造商和经销商也可以请求 CFE 编号，以跟踪他们在自己的模型中发现的安全隐患。危害披露和暴露协调委员会是 CFE 编号的保管人，负责将它们分配给安全隐患，并进行跟踪和发布。此外，组建一个附属小组将负责协助解决有争议的安全隐患。

下一步是什么？

根据开源原则开发的模型有可能在人工智能的未来发挥重要作用。根据行业和消费者期望开发和管理模型所需的框架和工具需要开放性和一致性，以便企业合理评估风险。透明度和对关键功能的访问权限越高，我们就越有能力发现、跟踪和解决安全隐患，以免造成广泛影响。我们的提案旨在通过现有的治理、工作流和结构提供灵活性和一致性。实施后，它们可以提供更有效的途径来解决有效管理 AI 安全的迫切需求。