AI安全标准止步之处——运行时防护必须开始

尽管人们都在讨论AI的安全风险，但有一个问题似乎被忽视了：AI系统只有通过暴露其最有价值的资产——模型和数据——才能运行。

与传统软件不同，AI并非简单地执行预定义的逻辑。它持续地将专有模型与敏感输入混合以生成输出，而运行的基础设施往往并非为保护计算过程而设计。

如此一来，传统安全措施便力有未逮。加密在数据存储或网络传输时有效，但在数据处理或操作时则不然。对于AI而言，危险尤其出现在模型部署之时。其参数被加载到内存中、初始化并大规模执行——这正是加密停止作用之处——使其面临潜在的未授权访问风险。在推理过程中，敏感数据流经同一暴露空间。其结果是一个高度脆弱的风险面：看似安全的AI系统，在最关键时刻实际上却处于无保护状态。

美国国家标准与技术研究院（NIST）、欧盟网络安全局（ENISA）和开放Web应用安全项目（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大型语言模型应用十大风险更具体地展示了AI系统在现实世界中是如何被攻破的。提示注入、敏感信息泄露、嵌入泄露、过度的输出透明度——这些并非理论上的担忧。它们是在部署强大模型时未对其揭示内容加以限制的副产品。

虽然这些问题常被框定为应用层问题，但其后果更为深远。模型行为的反复暴露可能导致有效的克隆；隔离不佳的嵌入可能揭示结构；推理滥用成为模型复制的途径。

OWASP的分类法阐明了一点：保护AI不仅仅是阻止不良输入。它关乎限制模型在运行后所暴露的内容——无论是内部还是外部。

共同的结论，未竟的任务

纵观NIST、ENISA和OWASP，它们在基本原则上达成了广泛共识：

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

然而，这些框架缺乏的是一种在模型部署和计算开始后强制执行机密性的机制。这种遗漏并非缺陷，因为标准定义的是意图和范围。实施通常留给系统设计者。

但它们留下了一个关键的缺口——随着AI系统的扩展，这个缺口会越来越大。

使用中加密改变格局

使用中加密改变了安全模型。它不再假设数据和模型必须暴露才能有用，而是将计算视为可以保护的对象。

实际上，这意味着：

• 模型在部署、初始化和执行期间保持加密状态
• 输入内容对执行环境而言始终不以明文形式可见
• 中间状态无法被检查或修改
• 基础设施不再需要被隐式信任

这并非取代治理框架或应用层控制——而是将其付诸实践。它恰恰在AI系统最脆弱的时刻，将风险原则转化为可强制执行的保证。

换言之，使用中加密是AI政策与AI现实之间缺失的一层。

治理结束与执行开始之时：保护AI计算

AI安全在运行时崩溃。一旦部署，AI模型和敏感数据必须在内存中暴露才能运行，这创造了一个传统控制措施——静态加密、传输中加密和治理框架——从未设计保护的风险面。

NIST、ENISA和OWASP等标准机构在定义AI风险、问责制和滥用方面取得了关键进展。但它们的指导在很大程度上将模型视为设计时构件，并假设执行环境是可信的。在实践中，模型参数和敏感输入在共享或外部管理的环境中被持续访问、重用和处理。

弥合这一差距需要重新思考AI安全，不应将其视为合规性练习，而应视为保护计算本身的问题——当模型处于运行状态、数据正在使用、暴露不可避免之时。使用中加密提供了一种可行的方法，能在AI生命周期的每个阶段保护AI模型和敏感输入的安全。