AI 安全标准的止步之处 —— 以及运行时保护的开始

随着人们对 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 生命周期的每个阶段保持安全。