AI Records / Retention / Legal Hold / eDiscovery Architecture Playbook

定位: 面向高级 AI PM / Senior BA / AI Product Architect / Enterprise Architect / Records Management Lead / Legal Operations Partner / Compliance Technology Lead / Risk Technology Lead / Internal Audit Partner, 把 AI records 从“日志保存”升级为可分类、可保留、可保全、可检索、可生产、可删除、可审计的金融零售生产能力。 适用范围: AI copilot、agentic workflow、customer service RAG、payment dispute assistant、credit underwriting copilot、AML / fraud assistant、complaint remediation agent、wealth advisory assistant、AI platform gateway、model evaluation and incident management。 重要说明: 本文是学习、作品集和内部架构训练材料, 不是法律意见、合规结论、监管解释、eDiscovery strategy、records schedule approval 或 litigation hold advice。正式项目必须由 Legal、Compliance、Privacy、Records Management、Risk、Model Risk、Security、Internal Audit、Business Owner、Operations Owner 和外部律师在适用场景下确认。适用性取决于 entity、product、jurisdiction、customer type、communication channel、record category、regulator、contract 和 litigation posture。

---

1. Executive Framing

AI 系统正在把传统业务行为拆成很多可观察但容易丢失的数字片段。

一个客户服务 RAG 回答, 可能包含 customer prompt、identity context、uploaded document metadata、system prompt、retrieval query、retrieved chunks、model output、agent edit、approval decision、final customer message、QA evaluation 和 incident flag。

这些片段不一定都要长期保存。 但其中一部分可能是 business record、regulatory record、litigation-relevant ESI、model governance evidence、complaint evidence 或 audit evidence。

本 playbook 的核心判断:

AI recordkeeping is not log retention.
It is obligation-aware evidence architecture.

中文表达:

AI 记录治理不是日志多存几天, 而是把 AI 影响过的业务事实变成可治理证据。

1.1 成熟能力要回答的问题

1.2 设计目标

• 让 AI records 有明确 owner。
• 让 record creation 靠近真实事件。
• 让 retention class 在 record-object level 决定。
• 让 legal hold 能跨系统传播。
• 让 deletion 永远先检查 active hold。
• 让监管、审计、诉讼和内部调查可以得到可解释 production。
• 让隐私最小化和 records obligation 同时被管理。

---

2. Source Anchors

以下官方来源是本文的架构锚点。本文不解释法律义务本身, 而是把这些来源转成 AI records、retention、legal hold、audit trail 和 production capability 的设计语言。

2.1 Regulatory Nuance

• FINRA / SEC / CFTC anchors 主要覆盖特定受监管实体和记录类别, 不能机械套用到所有金融零售 AI。
• 银行、信用卡、支付、保险、经纪、投资顾问、期货、加密、RWA 和 vendor AI 的义务可能不同。
• 客户沟通、广告、投诉、信贷、AML、trading、investment advice、privacy 和 employment records 可能有不同 schedule。
• Legal hold 来源可能是 litigation、regulatory inquiry、government investigation、subpoena、internal investigation 或 reasonable anticipation。
• Privacy deletion request 不等于可以删除所有相关记录。
• Retention period 到期不等于可以在 active legal hold 下销毁。
• Vendor 持有 AI records 不等于机构满足 prompt production 或 audit replay 能力。

2.2 NIST AI RMF Mapping

---

3. Record Object Taxonomy For AI Systems

3.1 Core Terms

3.2 Top-Level Record Families

3.3 Obligation-Based Categories

3.4 Classification Dimensions

3.5 Record Lifecycle

event occurs
  -> capture
  -> classify
  -> enrich metadata
  -> assign retention and access policy
  -> persist in retention-capable store
  -> monitor hold eligibility
  -> search / review / export when authorized
  -> disposition when eligible and no hold conflict
  -> disposition certificate

---

4. Retention / Legal Hold Reference Architecture

4.1 High-Level Architecture

AI channels and agents
  -> Record Capture SDK
  -> Metadata Enrichment Service
  -> AI Record Classifier
  -> Retention Policy Decision Point
  -> Records Registry
  -> Retention-Capable Storage
  -> Legal Hold Service
  -> Search and Review Workbench
  -> eDiscovery / Regulator Export Service
  -> Disposition Engine
  -> Immutable Audit Trail

4.2 Component Responsibilities

4.3 Storage Pattern

Metadata ledger: structured, immutable or append-only
Payload store: encrypted prompt / output / document / eval payloads
Index store: search index with rebuild lineage
Vector store: retrieval embeddings and chunk pointers
Archive store: customer communications and regulatory records
Evidence binder: exportable bundle for case, audit, regulator or litigation

4.4 WORM And Audit-Trail Capable Design

AI 架构语言应关注:

• original record preservation。
• modification and deletion history。
• actor identity and trusted timestamp。
• reason code and policy version。
• ability to recreate original record。
• integrity controls, signatures or hash chain。
• split duties for log administration。

Implementation patterns:

• object lock with retention mode。
• append-only event store。
• cryptographic hash chain。
• externalized audit ledger。
• periodic integrity verification。

4.5 Cross-System Hold Propagation

Legal hold 不能只设置在一个主数据库。 AI 相关 records 可能分散在 application database、chat transcript store、object store、vector database、search index、data warehouse、model observability platform、ticketing system、case management system、communication archive、vendor AI platform、backup and disaster recovery store。

Hold propagation evidence 应记录 hold id、scope definition、target systems、propagated time、acknowledgement、failed targets、retry status、exception owner 和 release time。

---

5. Prompt / RAG / Tool / Approval / Output / Eval / Incident Records

5.1 Prompt Records

Prompt records can include user message、system prompt version、developer prompt version、hidden policy instruction id、uploaded file metadata、identity context、channel metadata and safety classification。

Design questions:

• Is this prompt a customer communication, employee workpaper, privileged request or transient instruction?
• Was it used to produce a customer-impacting output?
• Does a legal hold need to find it by customer, product, model version or topic?

Controls:

• field-level minimization where lawful and usable。
• payload encryption。
• retention class at message level。
• prompt template version control。

5.2 RAG Records

RAG records include normalized query、retrieval query、repository、document id、chunk id、chunk text hash、source version、rank、score、filters and citation。

Design questions:

• Can the organization prove which policy or document version was retrieved?
• Can it distinguish retrieved-but-not-used from cited-and-used?
• Can legal hold freeze a source document version and retrieval metadata?

Controls:

• immutable source snapshots for regulated knowledge。
• source version id and content hash。
• retrieval event linked to generation event。
• index rebuild audit trail。

5.3 Tool Call Records

Tool records include requested tool、schema version、parameters、approval id、action hash、service account、execution time、response payload、side effect id、error and rollback result。

Design questions:

• Did the tool change money, account status, customer communication or case closure?
• Was approval required and bound to exact parameters?
• Is the tool call a record even if it failed?

Controls:

• approval-before-action。
• single-use approval token。
• immutable execution log。
• parameter hash。
• dual-control evidence for high-impact actions。

5.4 Approval And Override Records

Approval records include reviewer identity、role、authority、evidence viewed、decision、reason code、edits、override flag、time spent、conflict check and approval expiration。

Design questions:

• Was the reviewer independent of maker?
• Did the reviewer see original evidence or only AI summary?
• Was approval attached to final output or only to general intent?

Controls:

• evidence-first review UI。
• mandatory reason code。
• action-bound approval。
• conflict-of-interest rule。
• rubber-stamp monitoring。

5.5 Output Records

Output records include model output、edited output、final sent output、delivery channel、recipient、timestamp、citation list、refusal or escalation and required language。

Design questions:

• Is this customer-visible?
• Does it contain financial advice, credit decision, complaint response or fee information?
• Is final sent output different from model draft?

Controls:

• channel archive integration。
• final-output hash。
• pre-send review for sensitive categories。
• source citation preservation。

5.6 Evaluation Records

Eval records include dataset id、test case、expected behavior、model version、prompt version、score、defect category、reviewer note and release gate decision。

Design questions:

• Is eval evidence part of model governance retention?
• Does it include real customer data?
• Can audit reproduce the eval?

Controls:

• dataset lineage。
• sampling protocol。
• reviewer independence。
• test result immutability。
• release approval linkage。

5.7 Incident Records

Incident records include detection alert、timeline、affected model / prompt / tool、customer impact、records impact、containment、legal / compliance notification、recovery and CAPA。

Design questions:

• Did the incident involve lost records, wrong deletion, missing hold or improper output?
• Does it trigger legal hold or regulator production?
• Are incident communications themselves records?

Controls:

• incident evidence binder。
• preservation snapshot。
• impacted-record query。
• management signoff。
• post-incident audit replay。

---

6. Retention Matrix

以下是设计模板, 不是正式保存期限。实际期限由 Legal / Compliance / Records Management 按适用义务批准。

6.1 Retention Trigger Examples

6.2 Retention Classifier Output

{
  "record_id": "air_20260630_119_0001",
  "record_type": "rag_retrieval",
  "business_domain": "complaints",
  "business_object": "complaint_case_8814",
  "customer_impact": "customer_visible",
  "privacy_class": "financial_data",
  "retention_class": "business_regulatory_case_record",
  "retention_trigger": "case_closed",
  "hold_eligible": true,
  "export_profile": ["audit", "regulator", "litigation"],
  "policy_version": "records-ai-2026.06.30"
}

6.3 Retention Clock Controls

• clock_start_event must be explicit。
• system must prevent silent trigger changes。
• retention policy version must be preserved。
• derived records must link to source records。
• deletion eligibility must be calculated, not guessed。
• disposition must be blocked by active hold。
• manual deletion must require authorized exception and audit trail。

---

7. Legal Hold Trigger And Workflow

7.1 Trigger Sources

Legal hold may be triggered by filed litigation、reasonably anticipated litigation、regulatory inquiry、subpoena、civil investigative demand、enforcement investigation、internal investigation、customer dispute escalation、whistleblower report、data breach、AI incident、product-wide complaint pattern or employment dispute involving AI monitoring。

7.2 Hold Scope Dimensions

7.3 Hold Workflow

trigger intake
  -> legal review and matter id
  -> scope definition
  -> system inventory mapping
  -> hold creation
  -> hold propagation
  -> custodian notice and acknowledgement
  -> preservation verification
  -> collection and review
  -> periodic scope refresh
  -> release approval
  -> disposition review

7.4 Preservation Verification

---

8. Deletion vs Hold Conflict Handling

当 deletion request、retention expiry、privacy minimization、regulatory retention 和 legal hold 冲突时, 产品不能在 UI 层做简单判断。

推荐 priority decision 由 policy service 处理:

active legal hold
  -> block disposition and preserve
regulatory retention still active
  -> block deletion unless legal authority permits a controlled transformation
business retention still active
  -> preserve until schedule permits disposition
privacy deletion request
  -> evaluate exemptions, delete eligible non-held data, defer blocked data
retention expired and no hold
  -> disposition workflow

8.1 Conflict Decision Record

8.2 Design Rules

• A user-facing delete confirmation must not imply records under legal hold were destroyed.
• Deferral reason should be understandable but not disclose privileged matter details unnecessarily.
• Disposition jobs must query hold service in real time or use a verified hold snapshot.
• Hold release does not automatically delete; it triggers disposition eligibility review.
• Backups need a documented approach: restore controls, overwrite cycle or legal exception.
• Derived records must be checked; deleting prompt payload may not delete final business record.

---

9. eDiscovery / Export Workflow

9.1 Workflow

request intake
  -> authority verification
  -> scope definition
  -> search plan
  -> collection
  -> de-duplication and threading
  -> sensitivity and privilege review
  -> redaction
  -> quality control
  -> export package creation
  -> chain-of-custody signoff
  -> production delivery
  -> post-production audit

9.2 Search Scope

Search should support matter id、customer id or hashed customer reference、account / loan / transaction / case id、date range、channel、record type、model id、prompt template version、policy version、source document id、tool id、approver id、output text、keyword and semantic query、legal sensitivity tag and retention class。

9.3 Export Package

9.4 AI-Specific Export Issues

---

10. Immutable Audit Trail

10.1 Required Events

Audit trail should capture record created、record classified、retention policy assigned、record accessed、record modified、record deleted or dispositioned、legal hold applied、legal hold released、export searched、export collected、export redacted、export produced、policy changed and vendor export received。

10.2 Event Fields

10.3 Tamper-Evidence Patterns

• append-only event store。
• object lock。
• hash chain。
• periodic notarization or external hash anchoring。
• admin action monitoring。
• split role for audit configuration。
• immutable export of audit logs。
• automated integrity checks。

10.4 Audit Replay Test

For one customer-impacting AI decision, audit should reconstruct:

customer input
  -> retrieved sources and versions
  -> model and prompt versions
  -> AI recommendation
  -> human edit / approval / override
  -> tool execution
  -> customer-visible output
  -> retention class
  -> legal hold status
  -> access and export history

---

11. Regulator / Audit Production

11.1 Production Principles

• Produce from governed workflow, not ad hoc database dumps。
• Preserve original metadata and export metadata。
• Include chain-of-custody。
• Explain record taxonomy and system inventory。
• Separate responsive, non-responsive, privileged and sensitive materials。
• Maintain repeatability of search and collection。
• Record all redaction and exclusion decisions。
• Validate export completeness before delivery。

11.2 Regulator Readiness Pack

---

12. Operating Model

12.1 RACI

R = Responsible, A = Accountable, C = Consulted, I = Informed.

12.2 Governance Cadence

12.3 Role-Specific Focus

---

13. Metrics And KRIs

13.1 Completeness Metrics

13.2 Legal Hold And Production Metrics

13.3 Risk KRIs

---

14. Financial Retail Scenario Patterns

---

15. Vendor And Third-Party Design

Vendor arrangements should address record ownership、retention periods、legal hold propagation、export SLA、format and metadata、audit rights、deletion certificates、subprocessor handling、incident notification、data residency and privileged / confidential content。

Vendor exit must include full record export、metadata dictionary、hold-preserved records、deletion or transfer certificate、hash manifest validation、continuity of legal hold and archive import test。

---

16. 30-Day Lab

目标: 30 天内完成一套可展示的 AI Records / Retention / Legal Hold / eDiscovery architecture portfolio pack。

Week 1: Inventory And Taxonomy

Week 2: Retention And Hold Design

Week 3: Evidence And Production

Week 4: Operations, Metrics And Interview Pack

---

17. Interview Answers

Q1: What is the difference between AI logs and AI records?

30 秒:

Logs describe technical events. AI records are obligation-aware evidence objects that may support business decisions, customer communications, regulatory books and records, litigation preservation, model governance or audit replay.

2 分钟:

I would not treat every token trace as a long-term record, but I also would not keep only the final answer. A financial retail AI workflow may create prompts, RAG retrieval evidence, model outputs, approvals, tool calls, final customer messages, eval results and incident events. Each object needs classification: business domain, customer impact, privacy class, retention class, legal hold eligibility and export profile.

Q2: How would you build retention for AI systems?

Start with record inventory and taxonomy, then assign retention classes at record-object level. The retention clock may start at creation, output sent, case closed, account closed, model retired or incident closed. Storage should support WORM or audit-trail capabilities where required, and the disposition engine must query legal hold before deletion.

Q3: What does legal hold mean for AI records?

Legal hold means the organization must preserve relevant ESI and stop routine deletion for scoped records. For AI, scope can include prompts, outputs, RAG sources, vector metadata, approvals, tool calls, evals, incidents and vendor-held records. I would implement it as a cross-system service with matter id, scope, propagation, acknowledgement, verification and release workflow.

Q4: How do you handle a privacy deletion request during legal hold?

Route the request to a policy decision service. Records under active legal hold or mandatory retention are deferred or otherwise handled according to Legal, Privacy and Compliance direction. Eligible unrelated records can be deleted. The system records the decision, reason, authority, next review date and evidence.

Q5: What is needed for eDiscovery export of AI records?

A defensible export needs scoped search, collection protocol, metadata dictionary, native payloads, rendered views, redaction log, hash manifest, chain-of-custody and production manifest. AI-specific metadata includes prompt version, model version, RAG source ids, chunk hashes, human edits, approvals, tool calls, final sent output and policy decisions.

Q6: How do you prove an AI answer used the correct RAG source?

Preserve retrieval event details: query, repository, document id, chunk id, source version, content hash, rank, score and citation. The export package should include source snapshot or a verifiable reference to the authoritative source as it existed at the time of generation.

Q7: How would you explain WORM vs audit-trail alternative in architecture terms?

WORM prevents rewriting and erasure for preserved records. An audit-trail capable approach maintains complete time-stamped evidence of creation, modification and deletion so the original record can be recreated if changed. The exact regulatory acceptability depends on the entity and rule, but architecturally both require integrity, metadata, access controls and production readiness.

Q8: What would you put in PRD acceptance criteria?

Every customer-impacting AI output must link to prompt, model version, RAG source version, final sent message, human edits, approval if required and retention class. Legal hold must block disposition across all in-scope stores. Export must produce a manifest, metadata, payloads, hashes and chain-of-custody. Deletion must create a disposition certificate or conflict decision record.

---

18. Portfolio Deliverables

---

19. Common Pitfalls

---

20. Final Operating Principle

AI recordkeeping is a product and architecture capability, not a compliance afterthought.

For advanced AI PM / Senior BA / Architect, the practical skill is to turn every AI-influenced business event into a governed evidence object:

captured at source,
classified by obligation,
retained by policy,
preserved under hold,
produced with custody,
deleted only when eligible,
and replayable under audit.