How to Prove Your AI Did What It Said: A Developer’s Guide to Verifiable AI Outputs

如何证明你的 AI 确实执行了指令：开发者可验证 AI 输出指南

Originally published on the Invoance blog. Your AI’s output is gone the moment it returns. Most teams treat AI outputs like ephemeral function returns. The model responds, the response goes to the user, maybe a row gets written to a database, and that is the entire trail. 本文最初发布于 Invoance 博客。AI 的输出在返回的那一刻即告消失。大多数团队将 AI 的输出视为短暂的函数返回值：模型响应，响应发送给用户，或许数据库中会写入一行记录，这就是全部的踪迹。

When a customer disputes an answer six months later, when a regulator asks what your model produced for user 4f9a on March 14 at 2:47 PM, or when your legal team needs to defend a decision in a deposition, that database row is your evidence. The problem is that database rows can be edited, deleted, or corrupted, accidentally or otherwise. There is nothing in the row that proves it has not been touched since the AI generated it. There is nothing that proves your timestamp column was not bulk-updated by a migration last quarter. There is nothing that proves the input column matches the prompt the model actually saw. Your logs are a story you are asking someone to take on faith. That works until somebody has a reason to challenge them. 当六个月后客户对某个答案提出质疑，当监管机构询问你的模型在 3 月 14 日下午 2:47 为用户 4f9a 生成了什么内容，或者当你的法律团队需要在证词陈述中为某项决策辩护时，那行数据库记录就是你的证据。问题在于，数据库记录可能会被意外或恶意地编辑、删除或损坏。记录中没有任何东西能证明它自 AI 生成以来未被篡改。没有任何东西能证明你的时间戳列没有在上个季度的迁移中被批量更新。也没有任何东西能证明输入列与模型实际看到的提示词完全一致。你的日志只是一个故事，你要求别人凭信心去相信。这在没人质疑时尚可，但一旦有人有理由挑战它们，这种方式就失效了。

The first thing opposing counsel, an auditor, or a regulator will do is question the chain of custody. Without a cryptographic anchor, you have no answer to that question. AI attestation closes that gap. At generation time, you submit a small payload describing the call. The attestation service hashes the input, hashes the output, signs the whole thing with your tenant’s private Ed25519 key, and writes it to an append-only ledger. You get back an attestation ID and a public verification URL. From that point on, anyone can verify what happened, without trusting you, your database, or even Invoance. 对方律师、审计师或监管机构要做的第一件事就是质疑证据链。如果没有加密锚点，你将无法回答这个问题。AI 证明（Attestation）填补了这一空白。在生成时，你提交一个描述该调用的简短负载。证明服务会对输入和输出进行哈希处理，使用你租户的私有 Ed25519 密钥对整个内容进行签名，并将其写入一个仅可追加的账本中。你将获得一个证明 ID 和一个公共验证 URL。从那一刻起，任何人都可以验证发生了什么，而无需信任你、你的数据库，甚至无需信任 Invoance。

What attestation actually proves (and what it does not)

证明（Attestation）实际证明了什么（以及它不能证明什么）

Precision matters here, because half the confusion in this category comes from people overclaiming what cryptographic proof gives you. Attestation proves five specific things. First, the exact output the model produced at the moment of attestation. Second, the exact input the model received. Third, which model and version produced it. Fourth, that the record has not been altered since it was signed. Fifth, that the record was issued by your organization, identified by your tenant’s public key. 这里的精确性至关重要，因为该领域一半的困惑源于人们对加密证明所能提供的功能过度夸大。证明可以证实五件具体的事情：第一，模型在证明时刻产生的确切输出；第二，模型接收到的确切输入；第三，是哪个模型及其版本生成的；第四，记录自签名以来未被篡改；第五，该记录由你的组织发布，并由你租户的公钥标识。

Attestation does not prove that the output was correct, that the model’s reasoning was sound, that the input was truthful, or that any human acted on the output appropriately. It does not establish legal admissibility on its own, although it produces exactly the kind of self-authenticating record that Federal Rules of Evidence 902(14) is designed for. The distinction matters because attestation is a technical guarantee, not an editorial one. What it gives you is the evidentiary foundation everything else rests on. Without it, every downstream argument about your AI’s behavior starts from “trust our logs.” With it, every downstream argument starts from a signed receipt that any third party can verify in under a second. 证明并不能证明输出是正确的、模型的推理是合理的、输入是真实的，或者任何人类对输出的处理是恰当的。它本身并不能确立法律上的可采性，尽管它确实产生了《联邦证据规则》第 902(14) 条所针对的那种自我认证记录。这种区别很重要，因为证明是一种技术保证，而非编辑保证。它为你提供了一切事物赖以生存的证据基础。没有它，关于你 AI 行为的每一个后续论点都始于“请相信我们的日志”。有了它，每一个后续论点都始于一张任何第三方都可以在一秒钟内验证的签名收据。

Attestation proves what your model said. It does not prove the model was right. Those are different problems, and conflating them is how organizations end up overpromising on governance. 证明证实了你的模型说了什么，但它不能证明模型是对的。这是两个不同的问题，将它们混为一谈会导致组织在治理方面做出过度承诺。

Your first attestation in three lines

三行代码实现你的首次证明

The Invoance Node SDK ships with a single ingest method. You instantiate the client (which reads INVOANCE_API_KEY from the environment), pass the input, output, and model metadata, and you receive an attestation record with an ID, a payload hash, and a created-at timestamp. This call sits alongside your existing inference pipeline. It does not modify your prompts, your model, or your response shape. It does not introduce latency on your AI response, the attestation runs after generation, in parallel with your own logging. It is one network call. Invoance Node SDK 提供了一个单一的摄入方法。你实例化客户端（它会从环境变量中读取 INVOANCE_API_KEY），传入输入、输出和模型元数据，然后你将收到一条包含 ID、负载哈希和创建时间戳的证明记录。此调用与你现有的推理流水线并行。它不会修改你的提示词、模型或响应格式。它不会给你的 AI 响应带来延迟，证明是在生成之后、与你的日志记录并行运行的。这仅仅是一次网络调用。

import { InvoanceClient } from "invoance"; 

const client = new InvoanceClient(); // Reads INVOANCE_API_KEY=invoance_live_... from env

// 1. Run your model however you do today
const userPrompt = "Summarize this contract clause";
const modelOutput = await yourLLM.complete(userPrompt);

// 2. Attest the input/output pair
const att = await client.attestations.ingest({
  type: "output",
  input: userPrompt,
  output: modelOutput,
  modelProvider: "openai",
  modelName: "gpt-4o",
  modelVersion: "2025-01-01",
  subject: { userId: "u_42", sessionId: "sess_4f9a" },
});

console.log(att.attestation_id); // → "att_01HXY..."

What you get back

你将获得什么

The response includes the attestation ID, the SHA-256 hashes of the input, output, and combined payload, the timestamp the record was sealed, and a status field that lets the SDK distinguish a fresh write from an idempotent retry. Every field on the response is significant. The attestation_id is the handle you store alongside your own database row, so the next time anyone asks about that specific decision, you can hand them the attestation. The input_hash and output_hash are what a verifier compares against when they want to confirm the content has not changed since it was signed. The payload_hash is the canonical hash that was actually signed, and it is what the public verification endpoint validates against your tenant’s published public key. 响应包括证明 ID、输入、输出和组合负载的 SHA-256 哈希值、记录被密封的时间戳，以及一个让 SDK 区分新写入和幂等重试的状态字段。响应中的每个字段都很重要。attestation_id 是你存储在数据库行旁边的句柄，因此下次有人询问该特定决策时，你可以将证明提供给他们。input_hash 和 output_hash 是验证者在想要确认内容自签名以来未被更改时进行比较的对象。payload_hash 是实际签名的规范哈希，也是公共验证端点根据你租户发布的公钥进行验证的对象。

The status field is worth highlighting for anyone running at-least-once delivery patterns: if you submit the same payload twice, the second response returns status: “duplicate” instead of “accepted”, and your client gets back the original attestation. The system will not silently double-write. This means you can wire the call into a retry loop without worrying about ledger pollution. 对于任何运行“至少一次（at-least-once）”交付模式的人来说，状态字段值得特别注意：如果你提交了两次相同的负载，第二次响应将返回 status: “duplicate” 而不是 “accepted”，并且你的客户端会收到原始的证明。系统不会静默地进行双重写入。这意味着你可以将此调用放入重试循环中，而不必担心账本污染。

{
  "attestation_id": "att_01HXY7K3M9P2QV5R8WNBC4DAE6",
  "created_at": "2026-05-06T14:47:13.482Z",
  "input_hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
  "output_hash": "2c624232cdd221771294dfbb310aca000a0df6ac8b66b696d90ef06fdefb7a72",
  "payload_hash": "ef2d127de37b942baad06145e54b0c619a1f22327b2ebbcfbec78f5564afe39d",
  "status": "accepted"
}

How a third party verifies it independently

第三方如何独立验证它

This is the part that separates real attestation from “we have logs and we promise nobody changed them.” When you give an auditor, a customer, 这是将真正的证明与“我们有日志，我们保证没人改过它们”区分开来的部分。当你给审计师、客户……