评估企业AI安全：每位采购方都应能够回答的问题

企业AI安全领域发展迅速，但大多数组织仍难以严谨评估供应商的声明。这份由NSS Labs与F5、AWS和Microsoft合作编写的研究报告，为安全负责人和企业采购方提供了向供应商提出的具体问题、需要警惕的危险信号，以及做出有把握且有充分依据的AI安全决策所需的评估标准。

执行摘要

企业AI安全领域面临买方难题。各组织深知AI安全的重要性，但大多数组织缺乏可靠的框架，无法据此评估供应商声明、区分切实有效的控制措施与流于表面的措施，也难以要求供应商用真实环境中的证据证明其主张。

本文是NSS Labs两篇系列文章中的第二篇，由NSS Labs与F5、AWS和Microsoft合作编写。本文不再只是界定问题，而是帮助买方采取行动。第1部分阐明了为何仅保护AI模型并不足够，第2部分则在此基础上，针对7个关键能力领域提出切实可行的评估标准。

核心观点：AI安全采购决策不仅是技术决策，也是治理决策。采购方应要求提供可衡量的证据，而非架构图。这意味着需要为检测有效性、运营性能、审计要求和框架一致性设定量化基准，并根据实际环境进行验证，而非仅在孤立的测试场景中验证。

本文探讨了七大能力领域：输入威胁与指令控制、输出与数据外泄风险、性能下降情况下的系统韧性、策略与过滤器治理、智能体AI与授权委托、可观测性与取证，以及集成与互操作性。每一部分都围绕核心风险，列出采购方应向供应商提出的具体问题、有效解决方案应具备的特征，以及需要警惕的明确危险信号。

本文最后提出两项明确要求：购买前必须要求进行独立验证，并将验证作为一项持续实践，而不是一次性检查。拒绝接受实质性测试的供应商，反映出的是不成熟，而非实力。

归根结底，结论中的三句话值得认真对待：采购AI安全解决方案是一项会产生长期影响的治理决策。企业若能提前提出关键问题，就能更好地管理风险，避免本可预防的失败。AI安全不能依靠新奇概念或抽象理论取得成功，而要依靠问责、透明度和严谨的评估。

目录

引言：从认知到评估

制定量化评估标准

关键能力领域及买方应提出的问题

• 输入威胁、指令控制与规避检测
• 输出及数据外泄风险管理
• 韧性、稳健性、故障和性能下降处理
• 策略和过滤器有效性及治理一致性
• 智能体AI、工具调用安全与委托权限
• 可观测性、审计与取证
• 集成与互操作性

买家在购买前应提出的要求

为独立验证做好准备

结论：从声明走向问责

下载第1部分： 模型之外的AI安全：企业需要关注什么，以及为什么

简介：从认知到评估

随着AI以各种形式日益深入企业系统，新的威胁面也随之出现，企业不得不考虑AI安全风险。董事会、监管机构和管理团队逐渐认识到，AI系统不仅扩大了威胁面，还带来了新的运营、法律和声誉风险。因此，旨在降低这些风险的AI安全产品如今已成为企业安全团队重点关注的对象。

然而，意识到风险并不意味着已做好准备。尽管企业日益认识到AI安全的重要性，但许多企业仍难以有效评估这一新兴领域中供应商提出的主张。术语缺乏一致性，演示范围往往较窄，而相关保证通常基于架构，而非现实环境中的证据。采购方在决策时，既缺乏明确的方法来区分切实有效的控制措施与流于表面的措施，也难以判断实际覆盖效果。

在此前发布的白皮书《AI Security Beyond the Model》中，NSS Labs阐述了为何仅保护AI模型并不足够，以及为何必须从系统和治理层面应对企业AI安全挑战。真正的安全挑战出现在模型周边的系统中，也就是检索数据、调用工具和执行自动化决策的环节。

本文在此基础上，从理解问题进一步转向评估潜在解决方案，并帮助企业买家在筛选AI安全供应商时提出更有针对性的问题。与《AI Security Beyond the Model》一致，本文主要关注运行时防护机制（即模型外部用于执行策略、保护数据和生成审计证据的控制措施），同时也指出，模型安全和负责任的AI虽能降低模型的内在风险，却无法单独管理企业交互风险。随着AI系统逐渐融入企业工作流，安全决策与治理、风险管理及监管问责之间的联系日益紧密。组织不仅必须能够说明AI系统如何运行，还必须说明如何控制、监测和审计相关风险。

以下各节尝试将AI安全的核心能力领域重新定义为评估标准。其重点并非指定具体技术或架构，而是说明买方在为生产环境选择AI安全控制措施时，应能够了解、测试并为其选择提供依据的事项。

制定量化评估标准

评估AI安全性不能只看定性声明，还需要进行可量化的验证。买方应设定基准预期，以便客观比较不同供应商。

检测有效性：供应商应依据公认的独立测试机构所制定的标准化测试框架和方法，证明其检测能力。企业应要求供应商针对已知攻击模式提供可量化的准确率，并披露测试方法、覆盖范围限制以及误报方面的权衡。敏感数据泄露防护应能区分结构化数据类型与上下文敏感信息，并在不同基础模型和提示词复杂度下保持一致的检测准确率。

运营性能：买方应设定兼顾安全性和易用性的延迟阈值。系统应展示在生产规模负载下的性能，而非仅在孤立的测试条件下进行验证。误报率同样重要，过多的误报会导致告警疲劳，并促使用户采用影子AI。供应商应能够提供具有足够时间跨度的生产环境指标。

审计要求：要满足监管合规要求，需要全面记录日志，并提供足够详细的信息，以便在数月后重现事件。事件应以标准格式导出至SIEM，并尽可能降低延迟。数据保留要求因行业和用例而异。

框架对齐：供应商应将控制措施映射到公认的独立测试机构所制定的成熟框架。采购方应要求供应商使用标准化测试集和生产流量样本来证明这些能力。独立第三方验证可为控制措施的有效性提供可靠证据。

关键能力领域及买方应提出的问题

在基础层面，模型安全防护措施可以拦截恶意提示词、过滤不允许的内容，并执行简单的使用规则。这些能力必不可少，但许多影响重大的企业AI故障并非源于规则缺失，而是由于缺乏上下文、韧性和可见性。

例如，AI系统可能遵守所有已定义的内容策略，但仍会因信息聚合、推断或不当的上下文混合而泄露敏感信息。同样，系统在正常情况下可能会正确执行规则，但在高负载、部分服务中断或依赖项故障时，可能会出现不可预测的故障。

输入威胁、指令控制与规避检测

大多数AI安全控制措施都声称可以“过滤提示词”或“阻止恶意输入”，但这种表述往往过度简化了问题。在大多数AI系统中，风险不仅来自用户直接输入系统的内容，还来自嵌入在系统下游所使用内容中的指令。这些内容可能包括文档、网页、工单、电子邮件或知识库；只有具备足够的可信度，才能作为权威上下文处理。

作者

Bob Walder ，NSS Labs高级分析师
lan Foo，NSS Lab首席技术官兼产品执行副总裁

撰稿人

本研究由业内安全、云和AI领域的领导者共同开展。

Cameron Delano，高级解决方案架构师，F5
Jeanette Hurr，全球解决方案架构师，F5
Riggs Goodman III ，AI安全与隐私首席解决方案架构师，AWS
Raj Bagwe ，高级解决方案架构师，AWS
Zachary Riffle，安全架构师，Microsoft

买方应了解系统在运行时如何区分系统指令、开发者意图、检索到的内容和用户输入。对于采用检索增强生成（RAG）的架构，这种区分至关重要。如果检索到的内容可以隐式覆盖系统策略，那么即使从未提交明显的恶意查询，系统也容易受到间接提示词注入攻击。

企业应能获得以下问题的明确答案：

• 系统检测、评估和阻止政策所禁止的请求与指令的能力如何？
• 系统在检测并阻止通过输入提示词覆盖预期系统行为的企图方面表现如何？
• 系统在处理意图不明确的模糊或临界提示词时，能否尽量减少对正常使用的干扰？
• 系统能在多大程度上防止提交内容中嵌入的指令以非预期方式影响模型？
• 系统在应对通过异常格式、编码或提示词转换来规避控制的尝试时，效果如何？
• 系统在避免产生易于绕过控制的途径的同时，能否妥善兼顾安全性与基于角色的合法用例（例如培训模拟、红队测试和创意工作）？
• 系统在防止用户（或外部内容）影响或覆盖系统/智能体指令、路由规则、工具使用限制或其他“更高优先级”控制措施方面的效果如何？
• 系统能否有效检测、识别和管控模型的使用情况，以防止滥用或超出政策规定的过度使用及成本？
• 发生冲突时，系统能否在日志中显示最终采用了哪个指令来源（系统、开发者、检索或用户）？

在实践中，这方面的问题往往并非由明显的恶意提示词引发，而是源于不可信内容被引入AI上下文的方式。例如，攻击者可能在文档（如政策文档、内部Wiki页面或客户支持文章）中嵌入隐藏指令，随后AI系统通过复杂的多源检索管道摄取该文档。当模型检索到这些内容时，可能会将其中嵌入的指令视为权威指导，而非不可信输入。在内部内容可由众多人员编辑的企业环境中，这种间接提示词注入尤其难以检测。

例如，单个经过篡改的信息源不一定需要触发警报，立即阻止严重损害；从威胁行为者的角度来看，这样做也未必有利。相比之下，对多个数据源进行细微改动可能是更有效的策略，使系统行为随时间推移发生不易察觉但持续存在的变化，例如放宽响应约束、暴露内部工作流，或将攻击者控制的上下文置于系统策略之上。最终可能导致更大规模的敏感数据泄露。

因此，买方应评估AI安全控制措施是否将所有检索到的内容都视为潜在恶意内容，以及无论指令来自何处，是否都能一致地实施指令边界。

有效的解决方案能够高精度地区分用户输入与检索到的内容。当用户提示中出现指令覆盖尝试时，系统会将其阻止；当类似表述出现在合法的支持文章中时，系统则会进行适当处理。检测基于语义意图而非关键词，能够识别通过编码操纵或角色扮演场景实施的混淆攻击。供应商需要使用组织实际采用的多源检索RAG架构来演示检测能力。系统应提供具有代表性时间段内的生产环境指标，包括检测率、误报率和延迟。

需要警惕的情况包括：依赖通用提示词过滤；含糊地声称“模型会处理”；无法证明在对抗性条件下能够强制执行指令边界；未能提供有意义时间段内的生产环境指标；无法证明能够使用内部RAG架构进行检测；以及仅基于关键词进行检测，而不分析语义意图。

输入完整性的重点并非阻止恶意语言，而是在动态且不可信的环境中维护策略的权威性。

输出与数据外泄风险管理

AI生成的输出显然会带来重大风险，因为非人类智能体在生成答案时，可能从多个不同系统中提取了数据，而该答案向外部用户披露的信息可能超出原定范围。许多影响严重的故障并不涉及明确禁止的内容，而是在特定时间和情境下，向特定用户隐晦地披露了本不应披露的信息。

攻击者或未经授权的用户可能会提出一系列表面上无害的问题。单独来看，每个问题返回的都是允许披露的数据，但综合起来却可能让人推断或重构出敏感信息。例如，连接到内部工单和文档系统的AI助手可能会汇总运营问题、人员职责或系统配置，从而间接泄露内部架构或受监管数据。关键字过滤器很少能发现此类问题。相反，风险源于信息聚合和具体情境。采购方应评估输出控制措施是否考虑了累积暴露风险，以及系统能否说明限制某项响应的原因；这是实现治理和可审计性的一项基本要求。

买方应能获得以下问题的明确答案：

• AI安全控制如何结合上下文判断实际暴露了哪些信息，而不是仅仅识别输出中出现了哪些关键词或短语？
• 系统能否区分公开信息、内部信息和受监管数据？
• 即使用户请求看似合理或含义不明确，系统在防止模型通过响应泄露敏感数据方面的效果如何？
• 该保护措施涵盖哪些类型的敏感数据（例如个人数据、财务数据、企业机密信息），以及如何根据组织的需求进行定制
• 控制措施是否会根据用户角色、司法管辖区或数据来源进行调整？
• 系统能否解释输出被阻止或修改的原因？
• 系统能否对请求和响应实施控制，包括拒绝、编辑隐去和安全转换，并提供审计证据？
• 系统可以采取哪些措施来防止模型输出敏感数据（阻止、隐去、转换、警告、要求升级审查或审批）？
• 系统在防范提示词欺骗和规避策略方面的效果如何？这些策略试图诱骗模型间接披露数据，例如要求提供包含真实信息的“示例”“模板”“测试数据”或“摘要”。
• 系统能否防止并检测跨会话或跨租户的数据泄露，确保某一用户的会话、上下文或检索到的数据源中的信息不会出现在另一用户的响应中？
• 系统在防止模型泄露系统提示词、内部指令、隐藏策略或运行配置详细信息方面的效果如何？
• 系统在防止泄露训练数据、系统上下文、日志、连接器或检索内容中可能存在的凭据或机密信息（例如API密钥或令牌）方面的效果如何？
• 系统在防止模型生成有害、贬损性或带有严重偏见的输出方面效果如何，尤其是在用户诱导模型的边缘情况下？
• 系统在防止模型逐字输出大段受版权保护的内容，或以其他方式复制受保护内容方面的效果如何？
• 如果模型连接到企业内部内容（例如文档、Wiki或工单系统），系统能否防止模型复现超出用户查看权限的受限内部材料？
• 系统能在多大程度上阻止模型“逐步指导用户”执行有害工作流，或生成可能造成安全漏洞或不安全系统行为的操作性产物（例如脚本、命令或代码）？

当AI系统连接到实时企业数据源时，这些风险会显著增加；当AI系统将多个来源的信息整合到单个响应中时，可能会出现与输出相关的故障。

评估输出控制时，需要了解成熟的解决方案如何处理上下文数据暴露。上下文感知系统不仅能识别关键词，还能理解语义。这意味着系统应阻止输出结构化个人身份信息（PII），同时根据上下文允许输出公开信息。基于角色的策略执行可确保不同用户针对相同查询看到与其授权级别相符的不同输出。系统应检测跨会话的累积暴露，即单独看来无害的问题组合在一起可能会泄露敏感信息。阻止决定需要包含具体的策略依据、数据类型和授权要求。与现有数据分类策略集成可避免重复配置。

需要警惕的迹象包括：仅按关键词过滤；执行决策不透明；系统无法证明其能够实施基于角色的控制，例如，无论用户的授权级别如何，同一查询都会返回相同的输出；供应商无法以易于理解的方式解释特定输出被阻止的原因；以及缺少审计跟踪。企业应寻找相关证据，确认输出控制能够结合上下文和意图运行，并具备问责机制。

韧性、稳健性、故障和性能下降处理

企业通常根据安全控制措施在正常网络条件下的有效性进行评估，但AI安全需要采用不同的思维方式。一些影响尤为严重的故障并非发生在系统遭受直接攻击时，而是在系统因流量、复杂性、依赖项故障或意外的交互模式而承受压力时发生。

需要考虑的关键问题包括：

• 在异常漫长或复杂的用户交互（例如“马拉松式”会话）期间，系统在多大程度上能够保持可用性和响应能力？
• 在长时间运行的会话或多步骤智能体工作流中，是否始终一致地应用控制措施？
• 当系统突发收到大量重复、格式错误或无意义的输入时，如何防止资源耗尽或服务降级？
• AI安全控制措施失效时会发生什么？
• 策略检查是否会超时？执行机制在故障时会采用开放模式还是关闭模式？
• 依赖项发生故障时，系统如何平衡安全性与正常运行时间？这种行为是否可配置且可审计？

现实环境中的AI系统会在各种不同条件下运行，例如使用高峰、上游服务中断、身份提供商响应缓慢或检索服务性能下降。在这些情况下，策略执行组件可能出现部分故障，而非完全失效。例如，策略评估服务可能超时，或者为保持响应速度而跳过分类步骤。如果未谨慎处理这些故障，系统可能会在未向运维人员发出警报的情况下默认采取宽松策略；在智能体工作流中，这可能导致操作未经适当检查便继续执行。这些并非假设的极端情况，而是分布式系统中常见的故障模式。因此，采购方应要求供应商演示依赖项性能下降时AI安全控制措施的行为，并确认故障模式是否可预测、可见，且符合企业的风险承受能力。

具有韧性的系统不应在出现问题时简单地阻止一切，也不应在不发出任何提示的情况下允许不安全行为。相反，系统应以可预测的方式降级，清晰地报告错误，并在情况恶化时继续提供充分的保护。

设计完善的系统应明确记录每项依赖的故障模式。服务超时时，系统应以适当方式进入故障状态、记录事件、向安全团队发出警报，并向用户显示清晰的消息。在压力测试中，检测准确率需要保持较高水平，延迟必须控制在可接受的阈值内，且请求不得绕过安全检查。系统性能下降时必须以可预测的方式降级并发出警报，而不能静默降级；断路器必须及时终止失控进程。供应商应能够说明策略执行的可用性目标和故障行为；如果策略执行对关键任务至关重要，采购方可能会要求作出合同承诺。

危险信号包括：无法说明故障模式；缺少压力测试，或仅声称“系统在实际运行中尚未发生故障”；性能下降时不发出警报；缺少用于终止失控进程的断路器；无法证明压力测试期间检测准确率仍保持较高水平；以及系统在性能下降期间允许请求绕过安全检查。

策略和过滤器有效性与治理一致性

技术上先进但与实际运营脱节的AI安全控制措施，在业务一线往往难以有效落地。在企业环境中，策略决策通常并非简单的二元选择，也不是一成不变的，归根结底属于治理决策。

买方应考虑以下问题：

• 如何定义、审批政策，并对其进行版本管理和审计？
• 是否可以按角色、数据敏感度、地理位置或业务情境设定策略的适用范围？
• 系统能否解释做出某项决策的原因？
• 系统在支持制定反映组织特定合规要求（行业规则、内部政策、可接受使用限制）的策略方面表现如何？这些策略如何持续维护？
• 系统在帮助防止生成可能引发法律或合规风险的响应方面效果如何（例如，提供违反适用规则或标准的建议或指导）？

策略失效往往并非源于意图不当，而是技术执行与业务实际逐渐脱节。例如，AI系统可能正确阻止对某些数据类别的访问，但其执行方式却妨碍了合法的业务流程，导致用户转而使用未经批准的工具，完全绕过控制措施。相反，定义过于宽松的策略可能导致敏感信息在违反监管要求或合同义务的情境下泄露。久而久之，为处理投诉而进行的临时调整可能削弱策略的完整性和问责机制。因此，采购方应评估AI安全平台是否支持结构化的策略治理，包括记录审批情况、保留版本历史，以及审查策略执行结果的能力。如果缺乏这种规范，策略的准确性将变得主观，并且在发生安全事件后难以提供有力依据。

过度管控可能造成业务中断，并可能促使受挫的用户部署未经授权的“影子”AI系统；而管控不足则可能带来监管和声誉风险。这两种情况反映的都是治理问题，而非模型故障。

有效的策略管理应将策略视为代码，并采用版本控制、审批工作流和审计跟踪。策略变更在部署到生产环境之前，应获得安全、法务和业务利益相关方的书面批准。每项执行决策都应可追溯至具体的策略条款、版本、章节和授权逻辑。在条件允许的情况下，应根据系统仪表板提供的数据优化策略，例如误报趋势、高影响拦截，以及可用时的调优建议。

危险信号包括：决策过程不透明；临时调整，或声称策略能够“自我学习”却没有问责机制；策略变更缺少版本控制和审批工作流；执行决策无法追溯到具体策略条款；以及策略冲突缺少成文的解决规则。

智能体AI、工具调用安全与委托权限

随着AI系统从提供被动辅助发展为代表用户和其他系统执行操作，一类称为“委托权限”的新风险随之出现。智能体AI系统可以调用其他工具、修改记录，并以机器速度触发复杂的工作流。

评估智能体AI安全性的采购方应重点考察以下几个控制领域：

• 系统可以自主执行哪些操作？
• 权限如何受到限制？
• 当代理被授予代表用户执行操作的权限时，系统能在多大程度上有效限制代理可以或不可以执行的操作？
• 能否根据风险或具体情境对自主程度进行分级？如果没有明确限制，小错误可能会在多个系统间迅速扩散。
• 当系统能够与外部工具和智能体交互或利用它们时，系统控制措施在多大程度上能够防止提示词诱导系统执行超出预期边界的操作（即使用户“礼貌地提出请求”）？
• 系统能否有效防止或遏制递归循环或“失控”行为，避免智能体在未实现目标的情况下持续执行操作？
• 系统在防止未经授权使用工具、API/操作权限升级、过度自主行为/循环以及不安全的跨工具链式调用方面效果如何？
• 在多智能体架构中，系统能在多大程度上防止某个智能体检索或生成的敏感数据被不必要地传递给执行相关任务的下游智能体或工具？
• 在多智能体架构中，权限必须正确地跨系统边界传递。系统在智能体链中保留身份上下文的效果如何？能否确保下游智能体和工具严格按照原始用户的权限运行，而不是使用提升后的系统权限？

如果为了实现自动化而向AI系统授予广泛的工具访问权限，却未施加适当限制，往往会导致委托权限失控。例如，负责解决支持问题的AI智能体可能有权查询数据库、更新记录和通知用户。对指令的误解或意外的上下文可能导致数据被错误修改，或过早向客户发送通知。由于这些操作以机器速度执行，错误可能在人为监督介入前迅速扩散。在复杂工作流中，多个单独看来风险较低的操作可能叠加，造成严重后果。采购方应评估AI安全控制措施是否落实最小权限原则、是否要求对敏感操作进行确认，以及是否提供动态限制或撤销自主权限的机制。要防止权限在不易察觉的情况下升级，必须将智能体行为作为治理问题加以管理。

在设计完善的系统中，可通过架构控制措施降低这些风险。经过适当约束的系统会对每个工具实施最小权限原则，并明确记录权限边界。分级自主机制应要求中等影响的操作经过确认，高影响的操作获得人工批准；同时，保留身份上下文可确保智能体继承用户权限，而非系统级权限。当用户请求执行敏感操作时，智能体应仅检索已获授权的信息，并阻止未经授权的访问。熔断机制需要及时终止失控循环，并完整记录智能体的所有操作，包括推理过程、授权检查和结果。

这些控制措施体现了架构约束与行为约束之间的重要区别：架构约束通过技术手段阻止智能体调用特定工具或执行特定操作；行为约束则是智能体具备执行操作的能力，但被指示不得执行。对于安全关键边界，应尽可能采用架构控制，而不能仅依赖行为指令。

危险信号包括：智能体治理薄弱的警示迹象包括：允许智能体不受限制地访问工具，或仅依赖模型对齐来防止滥用；未记录各工具的权限边界；未能保留身份上下文，因而无法确保智能体继承用户权限；无法通过链式分析检测不安全的操作序列；以及智能体操作日志不完整，缺少推理过程和授权检查记录。

可观测性、审计与取证

当AI系统出现问题时，能够说明问题发生的过程和原因至关重要，甚至可能需要重现问题。

买方应确认能否端到端重建AI交互过程，包括输入、上下文、策略、输出、操作、调用的工具以及访问的数据。有效的系统还应支持持续监控和告警，使安全团队能够在事件升级前发现异常行为、不安全的操作链或意外的智能体交互。如果无法充分了解系统的行为方式，事件响应将只能依靠推测，治理工作也会失去可信度。

发生AI相关事件时，组织可能需要提供证据，而非仅作解释。如果没有关于输入、检索到的上下文、所应用的策略、输出和操作的详细记录，事件响应团队只能依据假设而非事实来还原事件。由于AI系统具有非确定性，其行为可能无法复现，这一问题尤为突出。例如，监管机构或内部审计人员可能会询问为何披露某些信息，或为何执行某项自动化操作。但如果缺乏端到端可观测性，组织便无法证明其意图、措施的适度性或控制措施的有效性。因此，买方应评估AI安全平台能否提供支持事件响应、合规报告和事件后复盘所需的可见性。

全面的日志记录应支持端到端重建请求，包括原始提示词、附带来源的检索上下文、身份和授权上下文、经过评估的策略及其版本、模型输出、所做的修改、向用户提供的最终响应以及下游操作。AI安全事件应能以极低延迟与SIEM系统集成，以便与网络流量和身份验证事件进行关联分析。严重违规必须及时触发警报，并提供足够的上下文以便立即响应；同时还应提供统一仪表板，通过趋势分析跟踪安全、性能和质量指标。

从治理、风险与合规（GRC）的角度来看，无法观测的系统就无法治理。

集成与互操作性

孤立运行的AI安全控制措施会造成可见性盲区，并阻碍协同响应。纵深防御架构要求各项控制措施共享遥测数据，并在不同安全层之间协同执行策略。

身份和访问管理：授权边界必须涵盖从用户身份验证、数据检索到最终输出的整个过程。组织应评估系统如何与身份提供商集成，以及角色变更能否正确传递。当AI智能体代表用户执行操作时，系统应保留授权上下文，并确保权限链可追溯；访问策略应继承现有的RBAC模型，无需重复配置。在检索层，系统应实施最小权限原则，根据请求用户的授权级别筛选文档。

SIEM集成：AI安全事件必须与更广泛的安全遥测数据相关联。为此，系统应采用OCSF或CEF等标准格式，以尽可能低的延迟将事件导出至SIEM平台。专有日志格式会导致这些事件无法与网络流量、身份验证事件和数据访问模式进行关联。组织应验证能否基于AI安全事件构建自定义检测规则，以及警报能否与现有事件响应工作流集成。

合规框架对齐：解决方案应将控制措施映射到成熟框架，明确具体的控制覆盖范围和审计证据；合规报告应可根据具体监管要求进行定制。仅笼统声称合规而未提供具体控制措施映射，并不足以满足要求。

API和自动化支持：现代安全运营需要通过编程方式进行控制，系统应支持策略即代码工作流以及与基础设施即代码的集成。未提供文档或频繁变更的API会导致集成不稳定。

买家在购买前应提出的要求

企业应更看重证据，而非架构图和精美的营销材料；更看重可重复性，而非华而不实的演示；更看重独立验证，而非自我宣称。

买方应要求供应商说明相关限制，支持符合实际情况的测试，并提供经得起审查的材料。

无法测试或解释的安全控制措施，不应被信任用于保护业务关键型AI系统。

为独立验证做好准备

评估AI安全性并非易事，但这不能成为缺少验证的理由。独立测试仍是企业增强信心的少数几种方式之一，有助于确认各项控制措施和功能是否如所述运行。

买方应要求采用能够反映真实环境的验证方法，包括对抗性输入、性能下降场景和治理要求。不愿参与有意义验证的供应商，体现的是不成熟，而非实力。

验证也不应被视为一次性工作。随着威胁不断演变、模型能力持续提升以及新攻击技术不断出现，在初始评估中表现良好的AI安全控制措施可能会逐渐失效。威胁形势瞬息万变，AI安全事件可能涉及前所未见的攻击方法。因此，组织除了开展初始测试外，还必须制定持续验证要求。

威胁情报集成：组织应评估供应商将威胁情报供应商和安全研究机构新披露的漏洞纳入更新的频率。供应商应证明其能够检测近期公布的攻击，而不只是依赖历史训练数据。与人工审查流程相比，自动摄取威胁情报可以更快地响应。

模型演进兼容性：基础模型的能力快速演进，安全控制措施也需要随之调整。组织应要求供应商提供针对不同基础模型的特定模型检测有效性数据，并警惕缺乏量化证据的笼统声明，因为这类声明可能掩盖盲区。供应商应明确提供新模型版本的认证时间表，以及认证空档期内的临时缓解措施。

买方主导的验证：组织应持续测试控制措施，而不能仅依赖供应商验证。买方应通过合同约定，获得定期开展红队演练、持续进行自动化绕过测试，以及对生产环境中的策略变更进行A/B测试的权利。限制客户测试或拒绝提供精细遥测数据，表明供应商的能力尚不成熟。

为确保防护措施在威胁形势不断演变的过程中持续有效，组织应将验证视为一项持续协作，而非一次性评估。如果缺少这种做法，即使设计完善的控制措施，最终也可能不足以应对新兴攻击技术。

结论：从声明走向问责

购买AI安全解决方案不仅是一项技术决策，也是一项会产生长期影响的治理决策。

企业若能提前提出关键难题，就能更好地管理风险、为决策提供依据，并避免本可预防的失败。

AI安全的成功不依赖新奇概念或抽象理论，而有赖于明确责任、提高透明度和开展严谨评估。

© 2026 NSS Labs®。保留所有权利。未经NSS Labs（“本公司”或“我们”）明确书面同意，不得复制、复印或扫描本出版物的任何部分，不得将其存储在检索系统中、通过电子邮件发送，亦不得以其他方式传播或传输。