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

Date: 2026-06-30 Status: evergreen Audience: experienced CBAP / financial retail PM / product architect / enterprise architect / AI governance lead / audit-risk partner Output: advanced architecture note for evidence trustworthiness, tamper-evident audit ledger, provenance claims and attestation chain design

---

Why Evidence Integrity Matters For AI Product / Architecture

AI 治理经常先关注模型是否准确、流程是否有人工复核、上线是否有审批、日志是否能查询。但在金融零售里，另一个更硬的问题是：

当争议、内审、监管问询、客户投诉或董事会质询发生时，团队如何证明这些证据本身没有被改写、替换、补录、选择性删除或脱离上下文？

Evidence integrity 不是普通记录保留，也不是运行观测，也不是监管报告签署。它专门回答证据可信度问题：

• 证据对象创建时的内容是什么。
• 谁或哪个系统生成了它。
• 它依赖哪些输入、版本、政策、来源和审批。
• 后续是否发生过更正、脱敏、封存、法律保全或访问。
• 审计方能否独立验证哈希、签名、时间顺序和因果关系。
• 出现冲突记录时，哪一条链路是可采信的。

在 AI 场景中，证据容易失真，因为 prompt、retrieved context、tool result、model output、human edit、approval decision 和 business side effect 往往分布在多个系统。只保存最终截图会丢失链路；只保存 observability trace 又不能证明业务批准和法律边界；只靠文档库权限也不能证明历史内容未被替换。

所以需要一个 evidence trustworthiness architecture：对关键证据对象进行结构化、哈希、签名、追加式登记、来源声明、可验证 attestation 和受控重放。

---

Concept Diagram

flowchart LR
    A[AI product event<br/>prompt, retrieval, tool, output, approval] --> B[Evidence collector]
    B --> C[Schema validation<br/>classification<br/>redaction profile]
    C --> D[Evidence object<br/>canonical JSON + content hash]
    D --> E[Event signer<br/>service key / HSM / KMS]
    E --> F[Append-only audit ledger<br/>hash chain / Merkle batch]
    F --> G[Provenance graph<br/>W3C PROV-style claims]
    F --> H[Attestation verifier]
    G --> H
    H --> I[Audit query and replay workbench]
    I --> J[Reviewer / risk / internal audit / legal hold]

    K[Retention system] -. policy id .-> C
    L[Legal hold service] -. hold state .-> F
    M[Raw evidence vault] -. restricted pointer .-> D

Design intent:

• Evidence object captures the minimum trustworthy payload and pointers.
• Ledger proves ordering, inclusion and later mutation attempts.
• Provenance graph explains causality and responsibility.
• Attestation verifier checks signatures, hash links, version claims and segregation of duties.
• Raw sensitive material lives behind restricted access; the ledger stores hashes, pointers and redaction status.

---

Core Architecture Model

1. Evidence object layer

Evidence object 是不可直接改写的事实容器。它不一定保存所有明文内容，但必须保存足以验证的结构化字段、hash、source pointers、classification 和 version set。

Key rule:

证据对象可以被更正、补充或脱敏派生，但不能就地覆盖。任何变化都必须生成新 evidence object，并通过 supersedes、redacts、corrects 或 legal-hold event 连接。

2. Ledger layer

Ledger 不是为了把所有内容上链。企业内部通常需要的是 append-only、tamper-evident、access-controlled ledger。

3. Provenance layer

W3C PROV 的思维可以转译为：

Example provenance claim:

recommendation:aml_sar_rec_884 wasGeneratedBy generation_run:run_651
generation_run:run_651 used prompt:p23
generation_run:run_651 used evidence_object:txn_timeline_778
generation_run:run_651 used policy:aml_escalation_policy_v12
recommendation:aml_sar_rec_884 wasAttributedTo service:aml-copilot-orchestrator
approval:aml_supervisor_905 reviewed recommendation:aml_sar_rec_884
case_note:case_record_441 wasDerivedFrom recommendation:aml_sar_rec_884

4. Attestation layer

Attestation 是对证据链的可验证声明，而不是一句“已审核”。

---

Evidence Object And Attestation Chain Design

Canonicalization

Hashing only works if the same logical evidence always serializes to the same bytes. For structured evidence:

• Use canonical JSON or another deterministic encoding.
• Sort object keys and normalize timestamp format.
• Exclude transport-only fields from canonical_hash.
• Include schema version in the signed envelope.
• Hash large payloads separately and reference them through payload_hash.

Example signed envelope

{
  "schema_version": "ai-evidence-object.v1",
  "evidence_id": "ev_kyc_decline_20260630_0192",
  "event_type": "ai.recommendation.reviewed",
  "created_at": "2026-06-30T16:04:11Z",
  "producer": "kyc-review-workbench",
  "use_case_id": "kyc_decline_recommendation_assist",
  "risk_tier": "high_customer_impact",
  "payload_hash": "sha256:a6c4e706f9cc2b7f0fdc22d7afec0289a08838e5b1f6a2250c5a7f2d3647c210",
  "canonical_hash": "sha256:5ccf44ad612a1fe87ecb92ab9b5ac38456f6a2b90a1d42f34bcd17a61ca9a112",
  "previous_event_hash": "sha256:7e0fd6b2169c3fcb4d921c2ddc0a4c3fd19c06d1dd57f3a67cba101b5fa43a71",
  "provenance_refs": [
    "doc_extraction_ev_881",
    "sanctions_screen_ev_341",
    "policy_decision_ev_204",
    "human_review_ev_1007"
  ],
  "signature": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "verification_method": "did:web:bank.example:keys:evidence-ledger-v4",
    "proof_purpose": "assertionMethod",
    "created": "2026-06-30T16:04:12Z",
    "proof_value_ref": "kms-sig://evidence-ledger-key-v4/sig_55102"
  }
}

Chain pattern

source evidence object
  -> retrieval attestation
  -> model generation evidence
  -> policy decision attestation
  -> human review attestation
  -> final business record evidence
  -> redaction or legal hold attestation when required

The chain should prove:

1. The final business record is derived from a specific AI output.
2. The AI output used a specific prompt, model route, source set and policy version.
3. The reviewer approved the exact evidence set or output hash they saw.
4. Any later redaction preserved a verifiable link to the original restricted evidence.
5. Any release or board MI statement can be traced back to population definitions and evidence objects.

---

Tamper-Evident Patterns And Privacy / Legal Hold Boundaries

Pattern 1: Hash chain for ordered events

Each event includes the previous event hash. If someone edits an old event, every later hash breaks.

Best fit:

• Low to medium throughput workflow events.
• Case-level timelines.
• Approval and tool-action sequence proof.

Design caution:

• Hash chains prove alteration, not truthfulness. You still need source, policy and reviewer attestations.

Pattern 2: Merkle tree for high-volume batches

Batch thousands of evidence hashes into a Merkle tree and store the root in the ledger. Audit can verify a single event was included without exposing the whole batch.

Best fit:

• Payment disputes, customer communications, call-center copilot outputs.
• Daily board MI evidence population snapshots.
• Eval result batches.

Design caution:

• Store the batch definition and ordering rule. Otherwise the root is hard to interpret.

Pattern 3: Signed event envelope

Each event is signed by the producing service or approval workflow. The signature binds the schema, payload hash, timestamp and producer identity.

Best fit:

• High-impact recommendations.
• Maker-checker approvals.
• Redaction and legal hold events.

Design caution:

• Key compromise is a governance incident. Key rotation and historical verification must be designed upfront.

Pattern 4: Dual-control evidence writes

For critical evidence classes, the writer service and approver service are segregated. A reviewer cannot approve an event they generated; an evidence platform operator cannot alter approval claims.

Best fit:

• KYC decline support.
• Credit policy advice accepted by underwriter.
• Payment dispute submission evidence.
• AML SAR recommendation review.

Design caution:

• Segregation must be enforced by identity, role, workflow state and audit query, not only by policy text.

Pattern 5: Redaction as derivative evidence

Redaction should not mutate original evidence. It creates a derivative object:

redacted_object.payload_hash != original_object.payload_hash
redacted_object.wasDerivedFrom = original_object.evidence_id
redacted_object.redaction_attestation = privacy_service_signature

Best fit:

• Audit workbench exports.
• Board MI packs.
• Cross-border review.
• Internal audit samples with masked customer identifiers.

Design caution:

• If the original is under legal hold, redacted derivatives must not become a bypass around hold or access controls.

Pattern 6: Legal hold as a ledger state

Legal hold is not a folder label. It is an attested state transition:

Design caution:

• Retention policy still owns normal lifecycle. Legal hold temporarily overrides deletion and redaction behavior for a defined scope.

---

Financial Retail Scenarios

1. AML SAR recommendation assistant

Trust question:

Did the AI recommendation use the approved transaction timeline, KYC risk facts and AML policy version, and did a supervisor review the exact recommendation before it entered the case file?

Evidence chain:

2. KYC decline support

Trust question:

If a customer challenges a decline, can the firm prove which document evidence, sanctions or policy facts supported the human decision, and whether the AI only recommended rather than decided?

Controls:

• Decline recommendation object is separate from final human decision object.
• Document extraction evidence references original document hash and extraction version.
• High-risk jurisdiction escalation has senior reviewer attestation.
• Customer communication is a derived output with redacted explanation and recourse route.

3. Credit policy advice

Trust question:

Did the copilot give policy-grounded advice to the underwriter without becoming the credit decision maker?

Controls:

• Policy advice output includes citation map and policy version hash.
• Underwriter decision has independent reason code and authority attestation.
• AI advice acceptance, edit or rejection is captured as a reviewer event.
• Population query can show all adverse-action-impacting cases where AI advice was viewed.

4. Payment dispute assistant

Trust question:

Was the evidence packet submitted under the correct network rule, with maker-checker approval tied to the exact submission input?

Controls:

• Dispute evidence packet hash covers receipts, transaction data, customer statement and rule checklist.
• Tool dry-run hash matches checker approval scope.
• Final submission event includes side effect id, idempotency key and approval id.
• Customer letter hash derives from approved communication draft.

5. Customer communication copilot

Trust question:

Can the bank prove what customer-facing message was approved, what version was sent, and whether sensitive fields were redacted in review exports?

Controls:

• Draft, human edits, approved final and delivered message are separate evidence objects.
• Material regulated claims require citation or policy support.
• Redacted audit sample is derived from delivered message hash.
• Vulnerable customer flag triggers enhanced review attestation.

6. Board MI and management reporting

Trust question:

Can management prove that AI governance metrics in the board pack came from defined populations and were not manually massaged?

Controls:

• Board MI snapshot has population definition hash, query version, data source attestations and reviewer sign-off.
• Exception counts reconcile to ledger event taxonomy.
• Redacted board pack links to restricted evidence population without exposing customer data.
• Late adjustments are separate correction events, not overwritten slides.

---

Metrics / Control / Evidence Model

Control design principle:

Treat evidence integrity metrics as release gates for high-impact AI, not as passive dashboard statistics.

---

Anti-Patterns And Failure Modes

---

Architecture Mapping To RAG / Agent / Copilot / Eval / Governance

RAG example

For a credit policy assistant, the architecture should prove that a generated policy answer used policy document credit_policy_v18, not a retired underwriting memo. The evidence chain hashes document, chunk, retrieval result, prompt and output. The citation map is not enough unless it is bound to source version and retrieval entitlement.

Agent example

For payment dispute automation, the agent must not submit a chargeback just because a model says the evidence is sufficient. The tool input hash, policy decision and maker-checker approval must match. If the agent retries, idempotency and side-effect evidence prevent duplicate action ambiguity.

Eval example

For AML narrative quality, the eval report must be tied to dataset sample hash, typology distribution, judge rubric, model route and prompt version. A release attestation should state which eval evidence supported the decision, while the ledger preserves the exact report used at approval time.

---

ADR Draft

# ADR: Tamper-Evident AI Evidence Ledger And Attestation Chain

Date: 2026-06-30
Status: Proposed

## Context

High-impact AI workflows in AML, KYC, credit, payment disputes, customer communication and board MI produce evidence across models, tools, reviewers and business systems. Existing logs and document repositories do not reliably prove that evidence was unmodified, approved against exact content, redacted correctly or preserved under legal hold.

## Decision

Implement a tamper-evident evidence architecture with:

1. Canonical evidence objects for high-risk AI events.
2. SHA-256 payload and canonical hashes.
3. Signed event envelopes using managed signing keys.
4. Append-only audit ledger with hash-chain and Merkle batch support.
5. PROV-style provenance graph for entity, activity and agent relationships.
6. Attestation chain for producer, source, policy, reviewer, redaction, legal hold and release claims.
7. Segregation between evidence writer, approver, platform operator and audit reviewer roles.
8. Redaction as derivative evidence rather than in-place mutation.
9. Legal hold as attested ledger state integrated with retention and deletion services.
10. Audit query workbench that verifies inclusion, signature, SoD, approval binding and replay completeness.

## Alternatives Considered

| Alternative | Reason not sufficient |
|---|---|
| Store screenshots and PDFs in a controlled folder | Does not prove content integrity, ordering, provenance or approval binding |
| Use only application logs | Logs may be mutable, over-collect sensitive data and lack business semantics |
| Use only observability traces | Traces show technical flow but not policy, approval, legal hold or release attestation |
| Put all evidence on public blockchain | Creates privacy, cost, governance and data exposure issues for financial retail evidence |

## Consequences

Positive:
- Stronger independent challenge and incident replay.
- Better proof that human approvals were bound to exact evidence.
- Clearer redaction and legal hold behavior.
- Board MI and release packs become traceable to evidence populations.

Tradeoffs:
- Requires schema discipline, key management and platform ownership.
- Evidence access UX must prevent privacy overexposure.
- Teams must design evidence events before release rather than after audit findings.

## Decision Tests

- A KYC declined customer challenge can be traced from final decision to AI recommendation, document hashes, policy version and reviewer attestation.
- A payment dispute submission cannot pass release readiness unless checker approval matches exact tool input hash.
- A board MI metric can be verified from population query hash and ledger inclusion proof.
- Redacted audit export can prove derivation from original restricted evidence without exposing raw PII.

---

Interview Answer

30 秒版本

我会把 AI evidence integrity 设计成证据可信度架构，而不是普通日志。核心是每个关键 evidence object 有结构化 schema、payload hash、canonical hash、生产者签名、append-only ledger 位置、PROV-style provenance 和 attestation chain。这样在 AML、KYC、信贷、支付争议或客户沟通出问题时，可以证明证据来自哪里、谁生成和审核、是否被改写、审批是否绑定到精确内容，以及脱敏和 legal hold 是否合规发生。

2 分钟版本

在金融零售 AI 里，监管或内审不会只问“有没有记录”，而会问记录本身是否可信。我的设计会从 evidence object 开始：把 prompt、retrieval、tool input、model output、human approval、final business record 和 redaction event 结构化，并计算 canonical hash 和 payload hash。关键事件由服务或审批系统签名后写入 append-only audit ledger，ledger 用 hash chain 或 Merkle batch 证明顺序和包含关系。

然后用 provenance graph 说明 entity、activity、agent 的关系，例如一个 AML SAR recommendation 使用了哪个交易时间线、KYC 信息、policy version 和 model route。Attestation chain 则分别证明来源、策略决策、人工审核、发布、脱敏和 legal hold。对高影响动作，我会强制 segregation of duties：证据 writer 不能自批，审批必须绑定 reviewer 看到的 exact evidence hash。

这套架构不替代记录保留、运行观测或监管报告流程，而是给它们提供可信证据底座。最终目标是让审计方可以独立验证哈希、签名、版本、来源、审批和重放完整性。

CTO 版本

我会把它作为平台能力建设，不让每个 AI 产品线自己拼日志。核心组件是 evidence SDK、schema registry、signing service、append-only ledger、provenance graph、attestation verifier、raw evidence vault 和 audit query workbench。

技术上，使用 deterministic canonicalization 和 SHA-256 做内容绑定，用 KMS/HSM 管理 signing keys，用 object lock 或 append-only event store 存储 ledger，用 Merkle roots 做高吞吐批次验证。架构上，ledger 不保存所有敏感明文，而保存 hash、pointer、classification、retention policy、redaction profile 和 attestations。隐私边界通过 restricted vault 和 derivative redaction objects 管理；legal hold 是 ledger state，不是人工文件夹。

治理上，我会把 verifier 结果做成 release gate：高风险 AI 用例必须通过 hash verification、signature verification、approval binding、SoD、legal hold readiness 和 replay completeness 检查。这样 CTO 能向董事会和监管解释：我们不是相信团队说证据没改，而是有平台机制证明证据链可验证。

---

7-Day Practice Plan

Practice completion standard:

• A non-project reviewer can verify one evidence object hash and trace it to a business decision.
• The design distinguishes raw restricted evidence from redacted derivatives.
• Approval binding and SoD are testable by query.
• Legal hold and retention integration are represented without turning the note into a records-retention policy.

---

Source Anchors With Links