AI 系统的可验证程度，取决于开发者以外的人在多大程度上能够依据证据，核查关于该系统的某项具体声明。声明是关于特定系统的精确陈述，例如是哪个模型回答了某个请求，或是哪些软件处理了这个请求。证据指开发者自身说法之外的材料，例如签名、由硬件签名的报告或数学证明。验证方是审查证据、判断声明是否成立的一方。每一次核查都建立在信任假设之上，即核查范围之外的组件或参与方，例如芯片制造商的签名密钥。

这一定义以 Brundage 等人 2020 年发表的一份报告为基础。报告把可验证声明定义为可证伪的陈述，证据和论证可以用来评估这类陈述为真的可能性[1]。因此，可验证性是一个程度问题。同一项声明也可能对一方而言可以核查，对另一方却不透明。

开发者的说法无法判定声明是否成立

如果提出声明的一方是该声明唯一的信息来源，它的说法就无法判定声明是否成立。这一点很重要，因为云端 AI 服务会处理个人数据，AI 智能体的用户也依赖开发者对安全措施如何执行的说明[2, 11]。Apple 在 2024 年介绍 Private Cloud Compute（PCC）时提出了同样的观点。PCC 是 Apple 的云端系统，用于支撑要求更高的 AI 功能。Apple 指出，当一项云端 AI 服务声称不记录某些用户数据时，研究人员通常无法验证这一承诺[2]。

PCC 的设计也缩小了承诺与验证之间的差距。Apple 称，PCC 完成请求后会删除用户数据，返回响应后“不会以任何形式保留用户数据”[2]。用户无法亲眼看到删除过程，因此这套设计增加了一些范围更窄、可以由设备核查的声明。按照 Apple 的设计，用户设备只把数据发送给满足条件的 PCC 节点：节点必须能以密码学方式完成远程证明，表明自己运行的是公开列出的软件。Apple 还承诺把这些软件的度量值（即密码学哈希值）发布到一份只追加的透明日志中，并发布生产软件镜像供研究人员使用[2]。设备可以确认自己在与哪个软件通信。但这个软件是否保留数据，要留给分析这些镜像的研究人员判断。

声明所在的七个层级

本站把声明归入验证栈的各个层级。下层支撑上层：要知道是哪个模型作答，先要知道运行它的是哪些软件和硬件。

层级典型声明证据示例
硬件与算力计算确实在真实硬件的受保护模式下运行。由硬件签名的证明报告[3]
软件与运行时处理请求的正是这份代码和配置。与公布的数值比对过的度量值[2, 3]
模型与数据这些就是发布的权重，签名之后没有改动。经过签名的模型文件哈希清单[6]
输出与内容这一输出由该模型根据该输入生成。推理证明或重新执行核查[4, 5]
智能体与行动所声明的护栏在该智能体作答之前已经运行。基于硬件的远程证明，表明护栏代码已运行[11]
评测与审计这个分数来自所声明的模型和测试集。在可信执行环境中运行的评测，或访问权限更深的审计[8, 10]
政策开发者或政府信守了关于训练算力的承诺。拟议方案：监测大规模训练所用的芯片[12]

六类证据及各自仍需信任的环节

每类证据回答的问题，都比读者关心的声明更窄。每类证据也都会把信任转移到别处。

密码学证明。零知识证明让服务商能够表明，某个输出是由给定输入和一个已承诺的模型计算得出的，同时不泄露模型权重。所谓对模型作出承诺，是指服务商公布一个由权重算出的密码学值，从而把自己绑定到这组权重上。在 zkLLM 中，模型架构是公开的，服务商对其权重作出承诺。作者报告，他们为一个 130 亿参数模型的推理生成证明，用时不到 15 分钟，证明大小不到 200 kB[4]。验证方仍要信任证明系统的可靠性（soundness），即虚假的命题无法得到证明。验证方还需要另外的证据，确认已承诺的权重就是对外宣传的那个模型的权重。

基于硬件的远程证明。可信执行环境（TEE）是处理器中一种由硬件隔离的执行模式。它会记录所加载软件的密码学哈希值（称为度量值），并把这些度量值写入证据，用植根于硬件的密钥签名后报告出来[10]。在互联网工程任务组（IETF）的远程证明架构中，验证方把这些证据与参考值和制造商的背书相比对。依赖方再根据结果决定是否信任这台机器[3]。远程证明能够确定真实硬件在受保护模式下加载了哪些软件。但硬件制造商以及所度量软件的行为仍然需要信任。

签名与透明日志。签名把特定的字节与签名者的密钥绑定在一起。Sigstore 的模型签名库会为模型的每个文件计算哈希值，汇总成一份清单，再为清单签名。用户因此可以核查，下载的模型是否就是某个已知身份签署的内容。如果通过 Sigstore 签名，签名事件会记录在一份只追加的透明日志中，签名者可以在日志里留意有没有并非自己所做的签名[6]。这类记录能够确定谁签署了什么，也让暗中替换变得可以察觉。至于所签名的模型好不好，这些记录什么也说明不了。

重新执行与抽样。核查方可以对每个请求或抽取的样本重复全部或部分计算，再比较结果。在 TOPLOC 中，服务商对模型中间激活值的紧凑哈希作出承诺；中间激活值是模型在各层内部计算出的数值。验证者重算这些哈希的速度快于原始生成。在作者的实验中，该方法检测出了模型、提示词和数值精度的改动，同时能容忍不同 GPU 之间的数值差异[5]。验证者必须持有所声明的模型。该方案也只覆盖它哈希过的内容。作者指出，如果服务商用更便宜的模型生成输出，再用所声明的模型计算用于哈希的激活值，该方案无法察觉[5]。

形式化证明。形式化验证力求在特定假设下，用数学证明表明某项技术声明为真[1]。“可保证安全的 AI”（guaranteed safe AI）框架提议把这一思路扩展到 AI 系统。在这一框架中，验证器组件将提供一份可审计的数学证明证书，表明系统相对于某个世界模型满足安全规约。世界模型是对系统如何影响外部世界的数学描述[7]。这份证书有多大用处，以它的规约和世界模型为限。

基于结构化访问的审计。关于开发者内部做法的声明，无法靠一次密码学核查来判定，因此审计方要凭借比公众更多的访问权限来审查这些声明。Casper 等人认为，黑盒访问（即向系统发出查询并观察其输出）不足以支撑严格的审计。他们还认为，访问权重以及代码等训练和部署信息，可以支持更深入的审查[8]。2026 年的一项提案把前沿 AI 审计定义为：第三方基于对非公开信息深入且安全的访问，严格核实开发者的安全与安保声明。该提案还描述了可信度逐级提高的四个 AI 保障等级[9]。拟议协议 Attestable Audits（基于远程证明的审计）在 TEE 中运行基准测试。这样做是为了让模型权重和测试数据保持机密，同时让用户能够验证与自己交互的是合规的模型[10]。审计把信任寄托于审计方的能力、独立性和访问权限。

核查通过后仍有三个缺口

验证结果只覆盖声明本身所陈述的内容，因此仍有三个缺口。

第一，远程证明表明加载了什么，却不能表明软件是安全的。例如，proof-of-guardrail 系统利用 TEE 远程证明，表明智能体的回复经过了某个特定的开源护栏。该系统的作者警告，开发者仍可能主动越狱这个护栏，也就是诱使它放行本应拦截的内容[11]。

第二，形式化证明的范围以其规约为限。如果规约或世界模型遗漏了某种危害，即使证明有效，它对这种危害也说明不了任何问题[7]。

第三，仍有一些参与方需要信任。IETF 的架构把没有任何证据描述的组件称为信任根，因此必须由背书为它们担保。就基于硬件的远程证明而言，验证方通常要信任芯片制造商及其硬件[3]。

一家假想的医院把各项问题对应到证据

按主题延伸阅读

来源

  1. Toward Trustworthy AI Development: Mechanisms for Supporting Verifiable ClaimsBrundage et al., arXiv · 2020年4月15日
  2. Private Cloud Compute: A new frontier for AI privacy in the cloudApple Security Research · 2024年6月10日
  3. Remote ATtestation procedureS (RATS) Architecture (RFC 9334)IETF · 2023年1月
  4. zkLLM: Zero Knowledge Proofs for Large Language ModelsSun, Li and Zhang, ACM CCS 2024 (arXiv) · 2024年4月24日
  5. TOPLOC: A Locality Sensitive Hashing Scheme for Trustless Verifiable InferenceOng et al., ICML 2025 (arXiv) · 2025年1月27日
  6. model-transparency v1.1.1, model signing library (README)Sigstore, GitHub · 2025年10月10日
  7. Towards Guaranteed Safe AI: A Framework for Ensuring Robust and Reliable AI SystemsDalrymple et al., arXiv · 2024年5月10日
  8. Black-Box Access is Insufficient for Rigorous AI AuditsCasper et al., arXiv · 2024年1月25日
  9. Frontier AI Auditing: Toward Rigorous Third-Party Assessment of Safety and Security Practices at Leading AI CompaniesBrundage et al., arXiv · 2026年1月16日
  10. Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution EnvironmentsSchnabl et al., arXiv · 2025年6月30日
  11. Proof-of-Guardrail in AI Agents and What (Not) to Trust from ItJin et al., arXiv · 2026年3月6日
  12. What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute MonitoringShavit, arXiv · 2023年3月20日

核查或更正本页

更正
提交更正请求 · 在 GitHub 编辑源文件 · 更正政策
验证记录

下方摘要可以说明你读到的文字是否与公开的源文件一致，但不能说明报道内容本身正确。这一摘要在构建时根据本页的 Markdown 源文件计算，并列入站点清单。

76756e7d60e37d56b71e8e4505ebac30e79a0594048f76ff86f3fb9cf93ae09a

查看源文件 · 清单