AI 证据完整性架构：Tamper-Evident Audit Ledger 与 Attestation Chain

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_EVIDENCE_INTEGRITY_TAMPER_EVIDENT_AUDIT_LEDGER_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

核心导读

AI 系统的证据风险不只来自“模型答错”，还来自证据对象可被重写、提示和上下文不可重放、生成内容与人工判断混在一起、日志只能观测不能证明、审计导出缺乏完整性验证。Tamper-evident audit ledger 的目标不是把所有内容放到区块链，而是让关键证据在生成、引用、修改、审批、导出和保留过程中具备可验证的完整性、来源、时间、责任和派生关系。

成熟架构要把 observability、audit、records、privacy 和 legal hold 分开设计：trace 能帮助调试，但不天然具备审计信任；原始证据要保护，脱敏证据要保留派生关系；删除和保留义务要通过状态与控制处理，不能用“不可变”口号掩盖合规冲突。

问题定义

AI 产品会产生大量“看起来像证据”的对象：

如果只保留普通应用日志，事后很难回答：

当时系统依据了哪些证据?
证据是否被改过?
生成结果是否来自这个模型/提示/检索版本?
人工是否覆盖了建议?
导出的证据包是否完整?
脱敏版本与原始版本是什么关系?
哪些对象被 legal hold 或 retention policy 约束?

证据完整性架构要解决的是“可信重放”，而不是“永久保存所有数据”。

核心原理/方法

Canonical evidence object 是基础。每个进入证据链的对象都应标准化成稳定表示，生成 hash，并绑定元数据：

{
  "evidence_id": "ev_...",
  "type": "model_output | retrieval_result | tool_call | human_review | eval_result | export",
  "created_at": "2026-06-30T12:00:00Z",
  "actor": "user | service | model | reviewer",
  "source_system": "case_workbench",
  "content_hash": "sha256:...",
  "canonicalization": "json-c14n-v1",
  "classification": "restricted | confidential | internal",
  "purpose": "investigation | approval | eval | audit_export",
  "retention_state": "active | legal_hold | expired_pending_disposition",
  "parent_evidence": ["ev_..."],
  "signature": "..."
}

核心模式：

这些机制的共同点是“不要求审计方信任应用数据库当前状态”，而是能用 hash、签名、时间、key、ledger entry 和 provenance 重新验证关键路径。

系统/架构模型

参考架构：

AI application events
  -> evidence capture gateway
  -> canonicalization and classification
  -> content-addressed evidence store
  -> tamper-evident ledger
  -> provenance graph
  -> attestation and signature service
  -> verification and export service
  -> retention, legal hold and redaction controls

关键组件：

Ledger entry 的最小结构：

{
  "ledger_seq": 1048576,
  "previous_entry_hash": "sha256:...",
  "event_type": "evidence_created | evidence_derived | approved | exported | hold_applied",
  "evidence_id": "ev_...",
  "event_hash": "sha256:...",
  "actor_id": "svc_case_ai",
  "key_id": "kms-key-version-12",
  "timestamp": "2026-06-30T12:03:12Z",
  "signature": "..."
}

关键机制与取舍

Tamper-evident 不等于 immutable everything。金融零售系统同时面对审计完整性、隐私、记录保留、删除、legal hold、客户数据最小化和权限控制。合理做法是让 ledger 追加记录状态变化、派生关系和销毁/保留证明，而不是永远暴露原始内容。

Observability 与 audit trust 要分层。OpenTelemetry trace 能说明系统调用路径、延迟和错误，但 trace 后端通常不是审计系统；audit ledger 要具备更强的写入保护、签名、访问控制、保留策略和验证能力。两者可以通过 trace id / evidence id 关联，但不能互相替代。

Canonicalization 是成败点。JSON 字段顺序、时间格式、浮点精度、附件编码、文本换行、脱敏 token 都可能导致 hash 不稳定。没有明确 canonicalization 版本，证据链会在验证时失效。

Redaction 要作为 derivative evidence。脱敏导出不应覆盖原始证据，也不应失去证明关系。系统应记录 redaction policy、执行者、时间、字段级变更、parent evidence hash 和 redacted content hash。

Key management 是信任根。签名没有 key lifecycle、rotation、revocation、HSM/KMS 控制和职责隔离，就只是技术装饰。高风险审批、导出和 legal hold attestation 应使用受控服务密钥或个人签名策略，并保留 key id。

Hash chain 与 Merkle tree 的取舍：

证据与控制

最小控制矩阵：

证据完整性测试应覆盖：

任意修改 payload 后 hash 校验失败
删除中间 ledger entry 后 chain continuity 失败
替换脱敏导出后 parent-child proof 失败
使用过期或错误 key 后签名验证失败
无审批导出被策略拦截
legal hold 状态下删除请求被阻断并记录

AI 特有证据还要绑定模型版本、prompt/template 版本、retrieval corpus 版本、tool schema、policy version、eval dataset version 和人工覆盖记录。否则生成结果无法重放，评估结果也无法解释。

金融零售/AI产品场景

AML SAR recommendation assistant 中，证据链应保存 alert、交易时间线、检索材料、AI summary、analyst edits、disposition rationale、SAR draft handoff 和 QA finding。AI 可以辅助组织证据，但 filing decision 和 narrative approval 必须由授权流程 attestation。

KYC decline support 中，系统要证明 decline recommendation 使用了哪些文件、校验结果、政策版本、人工复核和客户沟通模板。脱敏导出给审计或投诉处理时，应保留 redacted evidence 与原件的派生关系。

Credit policy advice 中，AI 输出可能影响额度、定价或例外审批。证据链要绑定政策版本、输入数据来源、模型/规则版本、人工审批和不可使用变量控制，避免事后无法解释 decision support 的依据。

Payment dispute or exception assistant 中，tool call preview、repair recommendation、maker-checker approval、ledger-impacting action 和 export evidence 必须分开记录。AI 不能用自然语言摘要替代可验证的 file、posting、settlement 和 approval evidence。

Customer communication copilot 中，生成内容、引用政策、人工编辑、最终发送版本和客户接收记录要关联。否则无法解释某段话是模型建议、人工修改还是最终对外承诺。

Board and management reporting 中，AI 生成的摘要需要绑定源指标、查询版本、截点、人工确认和导出 hash，防止管理报告被后续重算或手工修改后无法追溯。

反模式

最终心智模型

AI evidence integrity 的目标是让高风险 AI 决策支持系统具备可信重放能力：

canonical evidence object
+ content hash
+ signed envelope
+ tamper-evident ledger
+ provenance graph
+ redaction as derivative
+ legal hold and retention state
+ verification service
+ audit-ready evidence package

如果一个 AI 系统无法证明“当时使用了什么证据、谁做了什么、内容是否被改过、派生版本如何产生、导出包是否完整”，它就不具备金融零售高风险场景所需的证据控制能力。证据完整性不是加密细节，而是 AI 产品责任、架构边界和监管可解释性的基础设施。

---

SOTA 检查 (2026-07-01)

• C2PA 已迭代到 Content Credentials 2.3（2026-01-05 发布，spec.c2pa.org），本篇 Source Anchors 引用的 2.1 已非最新：2.2 于 2025-05-01 发布；2.3 新增 CMAF 分段签名支持直播流媒体、非结构化文本文件内嵌 manifest，并与 ISO/IEC TR 20226:2025 对齐。C2PA 截至 2026-01 有 6000+ 成员/关联方，仍是内容来源证明（content provenance）的主流标准；spec.c2pa.org 上已出现 2.4 草案页面但未确认正式发布日期。本篇引用的 manifest/claim/derivation 模式在 2.3 中依然成立。
• AI agent 审计轨迹开始标准化：IETF Internet-Draft draft-sharif-agent-audit-trail-00（datatracker.ietf.org，截至 2026-07 仍为 -00 草案）定义了自主 agent 的标准 JSON 审计日志格式——agent 身份/版本、trace id、动作分类（LLM 调用/工具调用/文件写/API 调用）、输入输出（PII 脱敏）、人工授权上下文、UTC 时间戳，并采用 SHA-256 hash chaining（canonicalization 依 RFC 8785 JSON Canonicalization Scheme）+ 可选 ECDSA 签名。这直接印证了本篇两个核心论点：canonicalization 版本化是成败点（RFC 8785 即 json-c14n 的一个具体现役选择），以及 hash chain + 签名是行业公认的 tamper-evidence 基线。
• 监管时间线已变（2026-05/06 确认）：EU AI Act 高风险（Annex III 独立系统）义务——含 Article 12 自动日志/record-keeping——经 Digital Omnibus（2026-05-07 临时政治协议，2026-06-16 欧洲议会批准、2026-06-29 理事会最终批准）从 2026-08-02 推迟至 2027-12-02（Annex I 嵌入受监管产品的 AI 推迟至 2028-08-02）；但 Article 50 透明度与生成内容标识义务仍按 2026-08-02 生效。对本篇的影响：高风险日志合规的硬期限后移，但证据完整性作为控制能力的方向不变，且生成内容标识（与 C2PA 类 provenance 机制直接相关）反而先到期。
• 本篇不随版本过时的框架性结论：canonical evidence object + content hash + signed envelope + append-only ledger 的分层；observability ≠ audit trust（trace 后端不是审计系统）；redaction as derivative（脱敏是派生证据而非覆盖）；key management 是信任根；tamper-evident ≠ immutable everything（legal hold/保留/删除走状态机）。这些与具体标准版本（C2PA 2.x、SP 800-53 修订）解耦，2026 年商用方案与 IETF 草案的设计均落在同一框架内。
• 库内交叉引用：本仓库 AIPA-120 已有两篇落地实现笔记可对照——docs/aipa/day74-audit-trail-otel.md（audit trail 与 OTel 分层，AIPA D74，计划完成于 2026-06）与 docs/aipa/day102-call-audit.md（agent 平台工具调用审计，AIPA D102），对应本篇 “Evidence capture gateway + Audit ledger” 两个组件的教学模拟实现。