企业级 AI 防护措施或许比前沿技术更重要

先别谈 AI 前沿技术。客户正要求企业为已在使用的 AI 加强防护，而 PCI DSS 的经验提供了一个有益的参考范例。

AI 监管的蜜月期已经结束。近期的披露引发了有关放缓前沿 AI 发展、强制实施控制措施的讨论。少数几项共识之一是，控制措施应独立于模型，并接受独立验证。

接下来会发生什么仍在讨论中，但监管机构已开始采取行动。欧盟《人工智能法案》正在分阶段实施安全义务，其中包括买方责任。在美国，NIST AI 风险管理框架正被采纳为合理注意标准。在全球范围内，OWASP 大语言模型应用十大风险已成为安全审查中常用的参考，而 ISO/IEC 42001 认证也开始出现在采购文件中。

这意味着，承担责任的不只是模型开发者。使用已发布模型的企业同样面临安全义务和风险，在高风险使用场景中尤其如此。客户安全问卷或招标书（RFP）答复中的错误答案，可能会使 B2B 交易陷入停滞。

PCI DSS 指明了方向

值得庆幸的是，这样的情形我们以前见过。二十年前，Web 应用安全主要依赖定期代码审计、静态扫描和开发人员的自律。随后，PCI DSS 第 6.6 项要求于 2006 年发布，并从 2008 年起强制执行。该要求规定，处理持卡人数据的组织必须审查所有应用程序代码以查找漏洞，或安装自动化技术控制措施。后来，代码审查这一选项被取消，组织必须采用技术控制措施。

但 PCI DSS 最初并非法律，而是一项合同标准。它重塑了市场，而且进程可能比立法更快，因为合同的推进速度快于政府立法。

同样，如今组织受到压力，需要为已部署的 AI 设置防护措施；这种压力并非来自监管机构，而是来自客户和合作伙伴，具体体现在安全问卷、招标书条款和保险单要求中。

解决运营问题，合规自然水到渠成

这种压力可能难以应对，因为 AI 治理不只是制定政策，更需要持续的技术证据。

我接触的许多企业都在生产环境中运行六个或更多模型，而且经常将这些模型串联起来或进行编排，让一个模型的输出成为另一个模型的输入。试想在这样的环境下，如何证明某一项政策已在整个系统中得到执行——例如，防止模型输出包含个人身份信息（PII）。手动审计多个各自独立配置的模型，会耗费开发人员大量时间。此外，大多数组织都难以应对未经批准且高风险的 AI 使用，例如员工将敏感数据粘贴到面向消费者的 AI 工具中，或 SaaS 提供商悄然启用新的 AI 功能。然而，全部责任都由企业承担。

面对这些复杂情况，相关要求可以归结为一项简单任务：证明你能够持续约束模型的输入和输出，同时记录相关活动以供核验。当应用程序调用模型、智能体调用工具，以及模型执行操作或触发工作流时，需要控制的是具体操作——工具调用、API 请求或工作流触发。

将安全防护移至推理链路

这一操作正是应用安全专家 20 年来一直致力于为应用流量建立的执行控制点。尤其是在推理流量经由共享基础设施路由时，推理链路就成为覆盖多个模型乃至未经批准的 AI 使用的理想控制点。AI 推理流量需要像其他重要的应用交互一样，根据流量来源及其意图进行传递、检查、身份验证和治理。与手动审计不同，推理流量治理能够扩展。

如何着手

鉴于监管趋势，组织现在就需要着手做好以下三件事：

1. 梳理你的责任范围，涵盖 SaaS API、托管端点以及影子 AI。
2. 将安全策略与执行机制从模型中分离，并将其置于推理链路中。
3. 确保审计轨迹的生成不受模型和智能体控制，因为已有证据表明，它们会试图篡改自身操作的记录。

何种监控和执行措施才算充分，目前仍在界定之中；但企业运营和安全团队清楚，哪些措施确实可执行、哪些控制措施会带来延迟和复杂性成本，以及哪些出于善意制定的规则可能导致错误结果。现在就让他们参与进来。AI 使用所带来的安全风险和义务确实存在，而你的客户和高管无疑更关心他们当下所面临的风险和义务，而非明天可能出现的前沿模型威胁。