思想领袖

AI 安全标准的终点——以及运行时保护必须开始的地方

mm
将 Unite.AI 添加到您在 Google 上的首选来源

在讨论 AI 安全风险时,一个常被忽视的问题是:AI 系统仅通过暴露其最有价值的资产——模型和数据——才能正常运行。

与传统软件不同,AI 不仅仅执行预定义的逻辑,而是不断地将专有模型与敏感输入混合,生成输出,通常在未被设计为保护计算的基础设施上运行。

这种情况下,传统的安全措施就不够了。加密在数据存储或传输时是有效的,但在数据被处理或操作时就不起作用了。对于 AI 来说,危险出现在模型被部署时。其参数被加载到内存中,初始化,并在大规模上运行——加密停止的时刻——暴露在潜在的未经授权的访问中。在推理过程中,敏感数据流经同样的暴露空间。结果是一个高度脆弱的风险表面:看似安全的 AI 系统,但实际上在最关键的时刻却没有保护。

标准组织,如国家标准与技术研究所(NIST)、欧洲网络与信息安全局(ENISA)和开放网络应用安全项目(OWASP),已经开始探索这一领域。他们描述了风险,指出了漏洞,并概述了治理原则。但是,他们没有规定如何在执行开始时保护模型作为知识产权和数据作为机密资产。一旦执行开始,标准就止步不前,需要重新思考 AI 安全——不仅仅是遵守规定,而是保护计算本身的问题。这就是加密在使用中的作用。

现代 AI 安全的盲点

大多数 AI 安全讨论仍然围绕着熟悉的领域:训练数据治理、访问控制、API 监控和负责任的用户政策。这些都是必要的。但是,它们都没有解决部署后会发生什么的问题,当模型离开存储库并成为一个活跃的系统时。

一旦部署,模型的参数不再是抽象的构件,而是活跃的、内存中的资产,持续被访问和使用,通常由多个租户或客户通过共享的 AI 服务使用。这一暴露发生在任何推理请求之前,因此通过引入敏感输入和外部可观察的行为而增加了风险。

将模型保护视为预部署问题,将推理安全视为运行时问题,忽略了问题的关键。在现实系统中,这些风险是重叠的。模型和数据在初始化、执行和输出时都暴露在外。仅仅依靠存储控制的安全措施无法解决这些暴露的问题。

NIST 做对了什么——以及哪里止步

NIST 的 AI 风险管理框架已经成为组织管理 AI 风险的基石。其结构——治理、映射、测量、管理——提供了一种有纪律的思考方式,以考虑责任、背景、影响和缓解措施,贯穿整个 AI 生命周期。

NIST 做得特别好的是,将 AI 风险框定为系统性风险,而不是偶然性风险。AI 失败很少是单点事件;它们源于模型、数据、人员和基础设施之间的相互作用。这种框定是至关重要的。

然而,框架在哪里止步不前,就是没有规定如何保护高价值的 AI 资产,一旦系统运行起来。模型参数被隐含地视为设计时的构件,而不是运行时的资产。执行环境被假定为足够可信。

在实践中,模型参数通常是组织拥有的最有价值的知识产权。它们被加载到内存中,复制到节点上,缓存和重用。如果 AI 风险管理未能考虑到模型在部署和执行期间的机密性,一个关键的资产将留在风险边界之外,就像一只坐鸭。

ENISA 和 AI 特定威胁的现实

ENISA 关于 AI 网络安全的工作将讨论推进了一步。其多层次框架区分了传统的基础设施安全和 AI 特有的风险,承认 AI 系统的行为不同,失败也不同于传统软件。

为什么这是重要的?AI 引入了不适合现有控制的威胁:模型提取、参数泄漏、共享租户暴露和执行期间的篡改。这些风险不需要异国情调的攻击者;它们自然地出现在高价值模型在共享或外部管理的环境中运行时。

ENISA 的框架隐含地承认,保护 AI 意味着保护行为,而不仅仅是代码。但是,就像大多数标准一样,它关注的是什么应该被考虑,而不是如何在模型运行时技术上执行保护措施。

OWASP 和可观察智能的代价

OWASP 的大型语言模型应用程序前 10 名 提供了一个更具体的视角,展示了 AI 系统在现实世界中如何崩溃。提示注入、敏感信息泄露、嵌入泄漏、过度输出透明度——这些并不是理论上的问题;它们是部署强大的模型而没有限制其暴露的副产品。

虽然这些问题通常被视为应用层面的问题,但其后果更深远。反复暴露模型的行为可能导致有效的克隆;不良隔离的嵌入可能会暴露结构;推理滥用成为模型复制的途径。

OWASP 的分类法表明,保护 AI 不仅仅是阻止坏输入;它还关乎限制模型在运行时内部和外部暴露的内容。

共享的结论——未完成的工作

在 NIST、ENISA 和 OWASP 中,有一个广泛的共识:

  • AI 风险贯穿整个生命周期
  • AI 系统引入新的威胁类别
  • 模型和数据是高价值的资产
  • 运行时暴露是不可避免的

这些框架缺乏的是一种机制,一旦模型被部署并开始计算,就能执行机密性。这种缺失并不是一个缺陷,因为标准定义了意图和范围。实施通常留给系统设计师。

但是,它们留下了一个关键的差距——随着 AI 系统的扩大,这个差距变得越来越大。

加密在使用中改变了等式

加密在使用中转变了安全模型。它不再假设数据和模型必须暴露才能被使用;相反,它将计算视为可以被保护的东西。

在实践中,这意味着:

  • 模型在部署、初始化和执行期间保持加密
  • 输入永远不会以明文形式暴露给执行环境
  • 中间状态不能被检查或修改
  • 基础设施不再需要被隐含地信任

这并不取代治理框架或应用层控制——它使风险原则成为可执行的保证,就在 AI 系统最脆弱的时候。

换句话说,加密在使用中是 AI 政策和 AI 现实之间缺失的层。

当治理结束,执行开始:保护 AI 计算

AI 安全在运行时崩溃。一旦部署,AI 模型和敏感数据必须暴露在内存中才能正常运行,创建了一个传统控制——静态加密、传输加密和治理框架——都无法保护的风险表面。

标准组织,如 NIST、ENISA 和 OWASP,已经在定义 AI 风险、责任和滥用方面取得了重要进展。但是,他们的指导主要将模型视为设计时的构件,并假设执行环境可以被信任。在实践中,模型参数和敏感输入被持续访问、重用,通常在共享或外部管理的环境中处理。

关闭这一差距需要重新思考 AI 安全——不仅仅是遵守规定,而是保护计算本身的问题,当模型是活跃的,数据正在使用,暴露是不可避免的。加密在使用中提供了一种可行的方法,来保护 AI 模型和敏感输入,在整个 AI 生命周期的每个阶段保持安全。

路易吉·卡拉米科(Luigi Caramico)是一位数据保护行业的资深专家,二十多年来一直站在网络安全创新领域的前沿。作为DataKrypto的联合创始人和CTO,卡拉米科正在开创数据安全的新时代,利用全同态加密(FHE)技术,承诺在人工智能时代彻底改变组织保护最敏感信息的方式。