AIREP：AI运行时治理中的每决策证据协议

# AIREP：AI运行时治理的单次决策证据协议
来源：https://arxiv.org/html/2608.21363
\(2026\)

###### 摘要

本文提出了一种用于记录自动化AI运行时治理决策的协议。当运行时对单个输出进行释放、阻止、推迟、编辑或升级时，AIREP将该决策记录为一个独立的签名对象，任何相关方均可在离线状态下进行验证，无需依赖生成该对象的运行时本身。该记录将决策表述为封闭动词集合中的某个动作，并基于明确的策略依据；其引用的输入、输出和证据均通过哈希值而非实际内容进行标识，同时明确声明证据的覆盖范围与非覆盖范围。记录通过SHA-256哈希链相互关联，每条记录的位置信息都被绑定，任何篡改或缺失均可通过重新计算检测发现。供应商、模型和领域的特定内容被限制在单个可选命名空间中，通过机械化的中立性测试确保共享格式不受其影响。文中描述了一个参考实现和双语言一致性测试套件，讨论了一些实现问题，并指出了跨实现规范形式对齐、新鲜度见证者及多运行时链等问题。该格式可供任何需要记录治理决策的AI运行时采用。

## 1 引言

自动化AI运行时正越来越多地面临具有法律或安全影响的决策。运行时可能释放某个输出、阻止另一个、将第三个交由人类处理、编辑第四个。在做出此类决策后，调查事故的审计员、检查记录保存义务的监管机构，或展示控制机制已触发的部署者都会提出一个具体问题：做出*这一*决策的依据是什么？其背后的证据未覆盖哪些内容？目前尚无广泛共享的记录可用于回答此问题。

从业人员通常使用的工具各自适用于相邻问题，但在此问题上效果有限。生成式AI活动的遥测规范（OpenTelemetry Authors, 2026 (https://arxiv.org/html/2608.21363#bib.bib11)）以时间跨度为粒度记录*运行了什么*，但未记录*基于何种权威*做出了*什么决定*。模型与系统卡片（Mitchell et al., 2019 (https://arxiv.org/html/2608.21363#bib.bib5)；OpenAI, 2023 (https://arxiv.org/html/2608.21363#bib.bib10)）包含权限与处置信息，但针对的是整个模型或版本，而非单个运行时决策。供应链证明对构建和内容进行签名（Open Source Security Foundation (2024), OpenSSF (https://arxiv.org/html/2608.21363#bib.bib9)；Torres-Arias et al., 2019 (https://arxiv.org/html/2608.21363#bib.bib12)；Newman et al., 2022 (https://arxiv.org/html/2608.21363#bib.bib8)），而非单次决策的治理处置。治理框架——如欧盟AI法案（European Parliament and Council of the European Union, 2024 (https://arxiv.org/html/2608.21363#bib.bib3)）、NIST AI风险管理框架（National Institute of Standards and Technology, 2023 (https://arxiv.org/html/2608.21363#bib.bib7)）和ISO/IEC 42001（International Organization for Standardization and International Electrotechnical Commission, 2023 (https://arxiv.org/html/2608.21363#bib.bib4)）——要求或鼓励进行日志记录、监控、文档化证据和风险管理，但未定义单次决策治理记录的在线格式。法律层面的分析也从另一角度得出相同结论：近期一项关于欧盟法律下AI代理的研究指出，具有不可追踪行为漂移的高风险代理系统目前无法满足该法案的基本要求，并指出带版本的单次决策运行时证据是标准中未明确规定的操作性产物（Nannini et al., 2026 (https://arxiv.org/html/2608.21363#bib.bib6)）。这一缺失的产物存在于这些工具之间，而非任何单一工具内部：单次决策、治理级别的证据记录仍是未定义领域。

本文提出AIREP（AI运行时证据协议），其中每条JSON记录精确对应一个运行时治理决策。该协议规定了记录所包含的成员、确保记录防篡改并绑定其序列位置的规范形式与哈希链，以及保持共享格式独立于任何特定运行时的机械化测试。我们首先描述记录及其成员（§2），然后给出完整性构造——规范形式、内容哈希、签名和链，以及协议支持的一种可重复性（§3）。随后定义一致性要求、确保记录供应商无关性的中立性测试，以及将记录绑定到外部规则集而不污染核心的可选配置文件（§4）。最后指出尚未解决的问题（§5）。

一个边界始终存在。AIREP规定的是证据记录的*形式*，而非其内容的真实性。记录证明在某个时刻、基于明确的动词和依据、依据指定的证据做出了一项决策，且此后未被更改；它并不确立底层AI输出的正确性。记录的范围成员在在线格式中标明了这一边界，§2.3将对此进行阐述。

## 2 记录

### 2.1 成员

协议的单元是单个JSON对象，记录一个运行时治理决策——运行时决定释放、阻止、推迟、编辑、升级或终止某个自动输出的时点。记录包含九个必需成员：版本常量airep_version和八个如下描述的结构成员。核心模式（JSON Schema draft 2020-12）在顶层设置了additionalProperties:false，因此符合要求的记录不包含此集合之外的成员，但有一个例外：保留的profiles对象，这是唯一允许的可选成员，也是唯一可以出现任何供应商、模型或领域特定内容的地方（§4）。

记录包含*指针，而非内容*。待决策的输入、结果和每条证据均通过*_ref指针引用，并在必要时通过*_hash摘要锚定；被引用的内容存储在带外。记录声明*某个输入被决策*及其*摘要是什么*，而非其内容。这保持了记录的小巧，并允许生产者在不使哈希失效的情况下保留敏感内容，因为哈希锚定的是引用而非载荷。

- • subject在空间和时间上标识决策：runtime（做出决策的系统）、producer（发出记录的软件，含名称和版本）、decision_index（整数，从0开始，在链中每个决策递增1）和timestamp_utc。可选的trace_id将一个会话的所有记录分组。
- • input需要input_ref（指向待决策输入的指针）和governance_state（机制无关的对象，描述决策时的治理上下文，例如策略版本）。特定于实现的机制不属于此处，应放在配置文件中。
- • claim陈述记录的主旨：assertion（单句陈述）和basis（断言所依据的门控或策略的非空列表）。记录不能在未命名至少一个依据的情况下对决策进行断言。
- • output记录结果为result_ref，附带可选的redacted标志；被编辑的结果被隐藏，但其哈希仍可锚定它。
- • evidence是将断言与其支持证据绑定的数组。每个条目是一个指针，包含来自封闭集合的type（§2.2）、ref和resolvable标志，以及可选的content_hash。生产者仅在验证者能够获取并检查被引用材料时才将resolvable设为true；验证者不得将resolvable:false的条目视为已验证的证据。因此，被编辑但已锚定的证据会保留在记录中，其缺失本身是可审计的，但不被视为证明。
- • directive是将决策压缩为封闭集合（§2.2）中的一个治理动词，以及产生该决策的policy_basis。如果claim以散文形式说明记录断言的内容，那么directive则说明运行时在明确权限下*做了什么*，作为一个机器可检查的令牌。
- • scope是区分成员（§2.3）。
- • integrity使记录防篡改并将其绑定到其链（§3）。

### 2.2 封闭词汇表

两个字段来自固定枚举，使得决策动词和证据类型可以跨运行时进行比较，无需进行逐供应商翻译。directive.verb恰好是release、block、defer、redact、escalate_to_human、kill之一——分别表示通过、拒绝、搁置、部分掩盖、转交人类或终止输出。evidence[].type恰好是retrieval、tool_call、memory、policy、human_approval、external_url、eval、other之一，其中other在保持集合封闭的同时，允许容纳前七种未命名的证据类型。任何特定于运行时的细化都应放在配置文件中，而非扩展核心枚举。

### 2.3 范围

使AIREP记录区别于普通日志条目的成员是scope。它需要两个数组：covers（记录中证据所证明的内容）和does_not_cover（其未证明的内容）。两者均由生产者填充。一条does_not_cover为空的记录即断言其证据覆盖了与断言相关的所有实质性内容——这是一个强有力的、可证伪的断言，而非默认跳过。由于记录可能依赖于已锚定但无法解析的证据，且验证者被禁止将此类证据视为已验证，因此记录在does_not_cover中声明其无法证明的内容。该字段使得记录能够在其在线格式中声明其自身保证的终点；这是记录断言决策*路径*而非输出*真实性*的原因。

### 2.4 实例演示

以下是与一致性测试套件一起提供的示例链中的第一条记录，位于examples/chain.jsonl。其integrity.current是记录规范形式的SHA-256哈希值，其integrity.signature是使用套件发布测试密钥对该值生成的Ed25519签名。签名值在下方为显示而缩写；其完整的128字符形式与其他记录值一起位于examples/chain.jsonl，读者可使用以下命令重新推导哈希并重新验证签名。

\{

"airep_version": "0.1",

"subject": \{

"runtime": "phionyx-core",

"producer": "phionyx/0.7.1",

"decision_index": 0,

"trace_id": "trace-chain-example",

"timestamp_utc": "2026-05-30T00:00:00Z"

\},

"input": \{

"input_ref": "sha256:ace06db3e39c9f0259980b2dc9ce388f1f61aeb27668a8d99fa6f70bbe93cd42",

"governance_state": \{"policy_version": "p1", "prior_context_bound": true\}

\},

"claim": \{

"assertion": "initial output released after safety + ethics gates passed",

"basis": \["safety_gate", "ethics_gate"\]

\},

"output": \{

"result_ref": "sha256:dc08be1aab29777176e5fde7c61bae87c82418f08345dc7c6dc346200ef95928",

"redacted": false

\},

"evidence": \[

\{"type": "policy", "ref": "policy://safety/v1", "resolvable": true\}

\],

"directive": \{"verb": "release", "policy_basis": \["safety_gate", "ethics_gate"\]\},

"scope": \{

"covers": \["safety gate fired", "ethics gate fired"\],

"does_not_cover": \["reasoning faithfulness not attested"\]

\},

"integrity": \{

"previous": "sha256:0000000000000000000000000000000000000000000000000000000000000000",

"canonical_json": true,

"current": "sha256:5aafe4898c6fd2e814c7871d3ba9b2d20eb106f3ccb115154741c263ae0ac87a",

"signature": \{"alg": "Ed25519", "value": "903e882b...64367607"\}

\}

\}

该记录表明运行时phionyx-core在其链的索引0处，因安全和伦理门控通过而决定release（释放）一个输出；它通过摘要指向输入和结果；它依据一个策略证据指针确认该决策；并声明它证明了这些门控的触发，但未证明模型推理的忠实性。previous字段携带了创世值（sha256:后跟六十四个零），标记链的第一条记录。§3的机制使此记录可被重现：

git clone --branch v0.1.1 https://github.com/halvrenofviryel/ai-runtime-evidence-protocol.git
cd ai-runtime-evidence-protocol
python3 spec/airep/v0.1/conformance/verify.py\
    spec/airep/v0.1/examples/chain.jsonl\
    --pubkey spec/airep/v0.1/examples/test_public_key.txt

验证器重新计算每条记录的哈希并重新验证每个签名，一个独立的基于不同加密技术栈的Node验证器逐字节推导出相同的哈希。

## 3 完整性与链

§2的成员说明记录断言了什么。integrity成员则说明该记录是否可被信任为生产者所写、按顺序编写且未被更改。它包含四个部分：规范形式、内容哈希、签名和后向链接。

### 3.1 规范形式

哈希只有在其覆盖的字节稳定时才是稳定的，而JSON允许一个逻辑对象有多种字节级序列化方式——键的顺序、空白字符、数字格式、字符串转义。因此，记录在哈希前会先转换为单一的规范形式，以确保两个独立的实现对同一摘要达成一致，并设置canonical_json为true来声明这一点。AIREP将规范形式固定为RFC 8785，即JSON规范化方案，它规定了键的顺序、空白和数字序列化方式。因为RFC 8785规定了数字的书写方式，生产者将任何确切表示至关重要的值作为字符串而非数字携带。

### 3.2 哈希与链

integrity.current是记录规范形式的SHA-256摘要，在计算时移除了current和signature成员，但保留了其他所有成员——包括后向链接previous。被移除的两个成员不能出现在自己的原像中；其他所有成员都可以。将previous保留在哈希内是承重选择：它将记录的内容绑定到其位置，使得签名的记录无法被提取并拼接到其他位置，或在链中稍后重放，除非改变previous贡献的字节，从而破坏current。记录形成一条链，其中每条记录的previous等于前一条记录的current，第一条记录的previous被设置为包含六十四个零的固定创世常量。验证器通过检测某些previous不再匹配前一条的current来发现被移除、重排序或拼接的记录，并检测不从创世开始的链。

### 3.3 签名

生产者对integrity.current进行签名，并将结果记录为\{alg, value\}。AIREP不强制使用特定算法：alg命名原语——Ed25519、HMAC或未来的选择——以便任何符合要求的签名者可互换，且验证者知道应用哪种原语。该格式固定了记录*被签名*以及*签名内容*（规范内容哈希），将原语的选择留给部署方。

### 3.4 记录绑定重放

AIREP支持一种可重复性形式，值得明确指出。给定一条记录或链，验证器基于*记录的*字节重新计算规范形式和摘要，并确认重新计算的current与存储值匹配，且链式链接成立。决策从其记录中被重放。这不是实时重新执行：协议不重新运行模型、不重新发出工具调用、不重新评估运行时，也不断言时钟确定性。其保证严格而言是相同的记录产生相同的摘要，且其所在的链链接仍然成立——这是证据的一种属性，与记录断言决策路径而非输出真实性的特性一致。如同任何加密日志，链使静默修改可被检测，缺失可被定位；它不为记录内容的真实性背书，§5将指出这遗留的问题。

## 4 一致性与中立性

### 4.1 一致性检查

一个*生产*的记录必须满足*生*