Sandia AI 安全指南为 Tri-Valley 初创企业敲响警钟

Sandia National Laboratories 向 Tri-Valley 初创企业派出四位研究人员，并发出警告：AI 的快速应用正在带来传统软件审查可能遗漏的风险。7 月 29 日的小组讨论将 Sandia 的 AI 安全方法置于商业场景中，而小型团队往往会在建立正式保障机制之前就部署模型。

该活动并未推出新产品、具约束力的标准或法规。其重要性在于 Sandia 展示的运营模式。初创企业应将数据、模型、集成环节和人工决策视为一个相互连接的系统，再针对现实中的故障和攻击测试该系统。

这一立场清晰地揭示了部署速度与安全证据之间的冲突。初创企业通过尽早发布功能、从用户处学习并迅速调整方向来竞争。Sandia 则从高后果环境的角度看待 AI，在这类环境中，一次无法解释的故障就可能破坏整个系统。

小组还挑战了一项初创企业常见的假设：通过信誉良好的提供商使用模型，并不意味着所有风险都会转移给该提供商。构建最终应用的公司仍然掌控其数据访问、检索层、工具、权限、用户体验和响应流程。

这使 AI 保障成为产品责任，而非最终的合规工作。摆在创始人面前的直接问题是：在客户、监管机构或攻击者提出要求之前，他们的团队能否提供有关系统行为的证据。

Sandia AI 安全从实验室走向初创企业运营

这场活动将国家安全关切转化为年轻公司已在面对的运营问题。

Daybreak Labs 于上午 11:30 至下午 1:30 在加利福尼亚州利弗莫尔举办了这场免费的 Lunch and Learn 活动。这家非营利孵化器为 Tri-Valley 地区的生命科学和深度科技初创企业提供支持。

小组成员包括来自 Sandia 的 Amanda Dodd、Gayle Thayer、Philip Kegelmeyer 和 Jonathan Crussell。他们的背景涵盖国家安全分析、安全算法、对抗性数据分析、软件安全和智能体 AI 工作流。

Sandia 国家安全计算与分析部门主任 Dodd 围绕快速应用带来的漏洞展开讨论。她将当前 AI 的扩张与 20 世纪 90 年代互联网的广泛普及进行了比较。

她的比较聚焦于不确定性，而非怀旧。互联网连接创造了有价值的服务，同时也让系统暴露于许多组织未曾预料到的攻击和故障模式中。如今，AI 在生成内容、推荐决策、有时还会采取行动的系统内部带来了类似的不确定性。

根据活动议程，讨论涵盖了速度与安全、创新与监管，以及人类与 AI 团队相关的风险。活动还探讨了政府与私营部门优先事项的交集。

Sandia 随后的小组讨论报道将 AI 威胁归纳为三类商业后果：知识产权损失、运营中断和监管风险。这些结果使技术弱点具有直接的财务和战略意义。

Sandia 安全算法部门经理 Thayer 解释称，安全关注点正从硬件和传统软件延伸出去。研究人员越来越多地审视算法本身，以及其使用过程中涌现出的行为。

这一变化至关重要，因为 AI 应用即便按设计运行，仍可能产生不安全的结果。模型可能泄露敏感上下文、接受恶意指令，或在原始测试条件之外出现不可预测的行为。

即使无人攻击，应用也可能失效。含糊的指令、不熟悉的数据、薄弱的评估标准或不恰当的自主程度，都可能造成严重错误。传统漏洞扫描无法识别所有这类问题。

Sandia 的方法包括红队测试，即在对手发现弱点前主动探测系统漏洞。研究人员还会在明确条件下，对可靠性、安全性和性能边界进行基准测试。

测试边界不同于报告单一有利的准确率得分。有效的评估会询问：系统从何处开始不再表现得可接受、哪些输入会触发这种变化，以及监控能否检测到它。

因此，该小组并非只是罗列 AI 风险。它将风险识别与可重复的测试、缓解措施和安全设计联系起来。这一顺序将抽象警告转化为工程纪律。

公开报道中没有迹象表明 Sandia 对参与活动的初创企业进行了认证或评估其产品。这场活动是方法和关切的交流，而非审计。

这一区别很重要。两小时的小组讨论无法确定某个具体 AI 系统是否安全。但它可以改变创始人在发布系统前提出的问题。

AI 快速应用让初创企业面临保障缺口

初创企业承受压力，是因为其发布周期短于理解每一种模型行为所需的时间。

一家年轻公司无需训练模型，就能将托管模型加入产品。它还可以在较短的开发周期内，通过应用程序接口连接客户文档、内部记录或外部工具。

由此形成的应用继承了多层不确定性。其行为取决于基础模型、系统指令、检索数据、软件集成、权限和用户输入。

任一层的变化都可能改变系统。模型提供商可能更新行为，检索索引可能纳入新文档，客户也可能启用新的集成。

这些变化造成了团队常称的保障缺口。产品的发展速度快于公司对安全性、可靠性和可接受行为所掌握的证据。

当 AI 系统能够采取行动时，这一缺口会变得更严重。智能体工作流是指让模型在有限人工干预下规划步骤并调用工具的应用。它们可以发送消息、编辑记录、执行代码或触发业务流程。

每增加一项权限，错误或被操纵的响应所造成的影响都会扩大。聊天窗口中的糟糕回答只是令人不便；同样的回答一旦传递给执行工具，则可能更改数据或泄露信息。

提示注入说明了这种差异。攻击者将指令置入用户输入或外部内容中，希望模型遵循这些指令，而非开发者预设的规则。

OWASP 维护的现行 LLM 风险清单将提示注入列为重大应用漏洞。该清单还涉及敏感信息泄露、供应链弱点、不当输出处理和过度自主性。

这些风险跨越组织边界。模型提供商负责保护其平台，而应用开发者控制提示词、检索、工具和访问规则。客户随后则控制用户行为、连接的数据和本地配置。

没有任何单一参与方能够看到完整系统。在事故发生前，这很容易导致责任被分散。

Sandia 的小组讨论将责任重新置于部署组织身上。政府可以贡献研究、框架和独立评估；但公司仍须为其产品和运营选择带来的风险负责。

这种责任并不要求初创企业复制一座国家实验室。它要求公司为自身使用场景界定何为安全行为。

临床研究助手和营销文案生成器不应采用完全相同的验收标准。前者处理的信息后果更高，因此需要更严格的证据、访问控制和审查。

初创企业还需将模型质量与系统安全区分开来。模型可能在常规任务中表现良好，却在对抗性输入下失效。它可能回答准确，却泄露用户不应获得的信息。

反过来也可能如此。应用可以防御常见攻击，却仍生成不可靠的建议。安全性与实用性有所重叠，但二者并不能相互保证。

这正是单一基准得分只能提供薄弱保障的原因。团队需要将测试与预期任务、可预见的滥用方式、访问边界和真实部署条件联系起来。

他们还需要保留记录。可搜索的知识库可在工程和产品团队之间保存模型版本、评估结果、事件和已接受风险。

文档并非开发完成后才添加的文书工作。它能让团队识别行为何时发生变化，以及此前的缓解措施是否仍然有效。

压力既是眼前的，也是长期的。企业买家已经会询问供应商的数据处理方式、模型提供商、访问控制和事件响应。未来的规则可能会让这些证据要求更加正式。

无法回答这些问题的初创企业，可能在遭遇技术性漏洞之前就失去交易机会。从这个意义上说，可信 AI 已成为产品可信度的一部分。

核心权衡在于速度与证据

Sandia 的信息并不要求放慢创新，但要求在 AI 获得更大权限前提供更有力的证据。

创始人通常将速度视为生存所需。快速发布能够获得用户反馈、验证需求，并帮助小公司与预算更大的组织竞争。

安全团队则从另一个角度看待同一次发布。在系统接触敏感数据前，他们希望具备威胁模型、测试、日志、访问边界和响应计划。

两种立场都有合理关切。若每项实验性功能都必须达到高后果标准才能推出，将给许多初创企业带来负担；若没有有意义的测试就部署自主系统，则会使客户暴露于他们无法看见的风险中。

实际答案是与风险相称的保障。低影响的写作助手需要的控制措施，应不同于能够修改财务、实验室或生产记录的智能体。

与风险相称的保障始于明确的背景。团队应记录谁会使用系统、系统可访问哪些数据、可采取哪些行动，以及哪些故障不可接受。

随后，公司会梳理可信威胁和常规故障模式。威胁包括恶意提示词、投毒数据、被盗凭证、遭入侵的依赖项，以及提取私密上下文的尝试。

常规故障同样值得重视。模型可能误解请求、编造来源、选择错误工具，或在自身假设失效后继续运行。

接下来是测量。团队根据真实任务、已知边界情况和对抗性示例构建评估集，并在运行测试前记录预期结果。

有效测试应有可观察的通过条件。“模型应当安全”无法衡量。“助手不得返回已认证用户工作区之外的记录”则足够具体，可以进行测试。

桑迪亚的红队方法引入了攻击者视角。测试人员会在完整应用中寻找意料之外的攻击路径，包括其指令、连接的数据、界面和工具。

更广泛的能源部实验室社区也描述了类似工作。一份由多家实验室联合发布的 AI 安全报告指出，静态基准测试不足以预测系统在陌生条件之外的行为。

该报告还指出了资源限制。全面评估会消耗计算能力、专家人力和时间。新模型的推出速度快于评估人员逐一进行彻底评估的速度。

这一限制对初创公司尤为相关。小型企业无法测试所有可能的输入，也无法复现提供商内部进行的评估。

但它们仍可测试自己能够控制的应用。聚焦的评估应覆盖公司的数据、工具、用户角色和影响最大的工作流程。

缓解措施应在测试之后跟进。团队可以限制权限、隔离不可信内容、验证输出、要求人工批准，或限制模型可以调用的工具。

最有力的控制措施往往是降低故障的后果。如果助手只起草一项操作，人类可以进行审查；如果助手直接执行该操作，公司就需要更严格的授权和监控。

人工审查并不天然有效。当大多数输出看似正确时，审查者可能变得松懈，尤其是在时间压力下。

因此，团队应识别哪些决策最依赖审查，也应提供足够的上下文，让人员能够发现可疑结果。

监控则形成闭环。日志应显示哪些模型、指令、数据源和工具共同促成了重要输出。缺少这些上下文，事件调查就会沦为猜测。

这些措施都不会带来永久保障。模型行为、应用代码、数据和攻击者都在变化，测试必须贯穿系统的整个生命周期。

在这里，速度与证据之间的冲突变得可控。初创公司可以先在受限环境中快速推进，再随着证据改善逐步扩大权限。

它可以从内部用户、合成数据和只读工具开始。系统达到明确门槛后，后续阶段再加入客户数据或有限操作。

这一路径将安全视为产品开发的一部分。它避免了“阻止所有实验”与“毫无限制地发布所有能力”之间的虚假二选一。

框架有帮助，但不能为产品背书

现有框架能够组织 AI 风险工作，但无法判定某家初创公司的应用是否足够安全。

NIST AI 风险管理框架为组织提供了四项相互关联的职能：治理、映射、衡量和管理。治理贯穿其他职能，而不是只在最后阶段出现。

该框架是自愿采用的，且面向广泛应用场景设计。其 AI 风险框架帮助组织将可信赖性纳入 AI 的设计、开发、部署、使用和评估。

对初创公司而言，“治理”意味着明确决策权并记录风险容忍度。必须有人决定哪些使用场景获准开展，以及哪些证据足以支持发布。

“映射”意味着理解背景情境。团队需要识别用户、受影响方、数据、依赖关系、预期收益和可能的伤害。

“衡量”涵盖测试与分析，包括性能评估、安全测试、不确定性评估，以及依据既定标准进行监控。

“管理”则将发现转化为优先事项和行动。公司根据严重程度及可用控制措施，接受、降低、转移或规避风险。

NIST 还在 2024 年 7 月发布了一份生成式 AI 概要文件。该文件将更广泛的框架调整用于应对生成式系统引入或加剧的风险。

这些资源提供了术语和结构，但不会检查某个产品、保证合规性，也不会认证模型的行为。

桑迪亚的立场似乎比仅仅采用框架术语提出了更高的技术要求。其研究人员强调红队测试、基准测试、安全设计，以及对性能边界的理解。

这一重点十分重要，因为治理文件可能与软件实际运行情况脱节。风险登记表或许声称已处理提示注入问题，但已部署的检索系统仍可能将不可信指令传递给模型。

证据应将每项已识别风险与相应控制措施和测试关联起来。公司还应了解在采取缓解措施后，哪些风险依然存在。

独立评估可以强化这一过程。桑迪亚将联邦资助的研发中心描述为能够提供无偏技术分析的来源。

不过，公开的小组报告并未宣布面向初创公司的通用桑迪亚认证服务。报告表达了希望识别行业能够满足保障需求的领域，以及国家实验室能够填补缺口的领域。

这是一项合作邀请，而不是一条已完成路径的证明。准入条件、工作范围、知识产权处理方式和采购安排，将决定个别初创公司能否参与。

桑迪亚已经运营了一些连接实验室、大学和小型企业的项目。其 RAIICE 项目旨在为涉及韧性能量的 AI 和机器学习工作提供开放数据集与技术路线规划。

RAIICE 展示了一种合作模式，但不应与 7 月的安全小组会议混为一谈。该小组并未宣布参会者已加入该项目。

这一差异揭示了桑迪亚信息中的怀疑视角。技术专长确实存在，创始人显然也需要它；仍不确定的是，这种专长能够在多大范围内触达商业团队。

国家实验室受特定使命、合同规则和资源限制约束。初创公司则在高度压缩的时间表下运营，可能需要在数日内得到答案。

合作模式必须弥合这两种节奏。它必须将研究方法转化为小团队能够执行、重复并向客户解释的测试。

监管带来了另一项不确定性。据报道，小组成员支持明确的规则，让行业能够负责任地承担 AI 风险；但该活动并未提出具体的法律标准。

规则能够澄清预期，但也可能随着模型和应用变化而过时。规定性要求可能奖励完成清单，却未改善真实行为。

以结果为导向的规则会带来不同的问题：它们可以告诉公司应实现什么结果，却未提供可负担的证明方式。

近期最好的信号将是实际证据。公开测试方法、可复用的评估工具、易于获取的数据集，以及有记录的初创公司合作案例，将表明合作愿景正在落地。

在此之前，公司不应声称采用框架即可证明安全。它们应说明所使用的控制措施、已进行的测试，以及仍观察到的局限。

创始人与买家接下来应关注什么

下一项考验在于，桑迪亚的风险语言能否产生可重复的实践、可信的合作关系和更清晰的市场预期。

第一个信号是面向小型企业的具体合作路径。桑迪亚表示，希望识别行业能够满足保障需求的领域，以及国家实验室能够填补缺口的领域。

有用的路径应明确符合条件的项目、可提供的专业能力、数据处理要求、预期交付成果和合作时间表。公开案例研究将使这一模式更易于评估。

如果这些细节出现，它们将强化小组的核心主张：国家实验室的方法能够超越讨论，并支持商业开发。

如果没有这样的路径出现，这场活动仍将是有价值的外展工作，但能提供的实际帮助有限。初创公司仍需要自行组建测试计划，或聘请外部专家。

第二个信号是与真实应用绑定的技术验证。创始人应关注已发布的评估是否涵盖提示注入、数据泄露、模型操纵、不安全的工具使用，以及偏离正常测试条件时的行为。

最有价值的工作将报告失效条件和残余风险，而非只展示有利分数。它应解释测试后发生了哪些变化，以及缓解措施是否经受住了又一轮攻击。

这类证据将强化“可信 AI 能够带来竞争优势”的论点。当公司提供可重复的结果时，买家就能更有信心地比较供应商。

缺乏证据会削弱这一论点。仅凭安全措辞无法将一个产品与另一个产品区分开来，尤其是在所有供应商都作出类似承诺时。

第三个信号是从广泛框架转向更清晰的客户和监管预期。NIST 正在修订 AI RMF 1.0，并为网络安全和关键基础设施开发额外的概要文件。

创始人应关注企业问卷、采购要求、保险审查和行业规则是否开始要求类似证据。趋同将减少关于哪些控制措施值得尽早投资的不确定性。

碎片化则会带来更重的负担。初创公司可能需要面对每位客户、监管机构和合作伙伴提出的不同评估格式。

买家也能影响这一结果。他们应询问供应商：哪些模型和数据源支持某项工作流程，系统能够采取哪些行动，以及供应商如何测试访问边界。

他们还应询问模型更新后会发生什么。如果提供商改变行为，或应用获得新的工具，先前的评估只能提供有限保护。

开发者应将每一项新增权限视为新的安全决策。将助手连接到电子邮件、源代码、客户记录或实验室数据，会改变故障的后果。

知识工作者也应理解这些边界。他们需要清晰信号，了解哪些信息可以进入 AI 系统，以及哪些输出需要独立审查。

桑迪亚的小组并未解决这些问题，但它让初创公司更难继续推迟面对它们。

最持久的教训是，AI 安全涵盖模型周围的完整运行体系。数据、指令、软件、权限、用户和监控都会影响结果。

这一教训也明确了创始人现在应采取的行动：定义系统，按影响程度排列最严重的失败情形，测试这些失败，减少权限，并保留证据。

随后，应询问每项新能力是否配得上它获得的权限。一个有说服力的演示不是保障案例，提供商的声誉也不能替代应用测试。

如果公司将这种纪律转化为日常产品工作，桑迪亚的 AI 安全指导才最具意义。创始人应从选择一项后果重大的工作流程开始，并记录其风险、控制措施、测试和未解决的限制。