AI Records / Retention：记录留存与法律保全架构
AI records architecture 解决的是：哪些 AI 事件构成业务记录、监管记录、客户沟通记录、模型治理证据或潜在诉讼证据；这些记录应保留多久、如何保全、如何检索、如何出示、何时删除，以及 legal hold 与隐私删除请求冲突时如何处理。AI 系统如果只把 prompt 和 response 当 debug log，就会在客户投诉、监管检查、法律保全和 eDiscovery 中
AI Records / Retention / Legal Hold / eDiscovery Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_RECORDS_RETENTION_LEGAL_HOLD_EDISCOVERY_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| FINRA Rule 4511 | https://www.finra.org/rules-guidance/rulebooks/finra-rules/4511 | 用 books and records、preservation period 和 SEA Rule 17a-4 reference 连接金融记录义务 |
| SEC Rule 17a-4 electronic recordkeeping overview | https://www.sec.gov/investment/amendments-electronic-recordkeeping-requirements-broker-dealers | 用 WORM / audit-trail alternative、third-party recordkeeping 和 prompt production 定义电子记录保存能力 |
| CFTC 17 CFR 1.31 | https://www.ecfr.gov/current/title-17/chapter-I/part-1/subject-group-ECFR26e2c365a191fa7/section-1.31 | 用 authenticity、reliability、metadata、system inventory、readily accessible 和 production 设计监管记录层 |
| FRCP Rule 37(e) | https://www.law.cornell.edu/rules/frcp/rule_37 | 用 ESI preservation、reasonable steps、routine operation 和 sanctions risk 设计 legal hold control |
| NARA records management guidance | https://www.archives.gov/records-mgmt/policy | 用 records lifecycle、ERM requirements 和 disposition 思维定义记录治理 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI 记录风险、证据质量和治理指标 |
适用性说明:
- 本文是架构、产品和治理学习材料, 不是法律意见、合规结论、监管解释或 eDiscovery legal strategy。
- 真实适用范围取决于 entity type、product、jurisdiction、customer segment、communication channel、record category、regulator、contract 和 litigation posture。
- 金融零售场景要由 Legal、Compliance、Privacy、Records Management、Risk、InfoSec、Model Risk、Operations 和业务 owner 共同确认 retention schedule、legal hold scope 和 production protocol。
核心导读
AI records architecture 解决的是：哪些 AI 事件构成业务记录、监管记录、客户沟通记录、模型治理证据或潜在诉讼证据；这些记录应保留多久、如何保全、如何检索、如何出示、何时删除，以及 legal hold 与隐私删除请求冲突时如何处理。AI 系统如果只把 prompt 和 response 当 debug log，就会在客户投诉、监管检查、法律保全和 eDiscovery 中失去可复盘性。
金融零售 AI 的记录范围不止最终答案。Prompt、RAG query、retrieved chunks、tool call、policy decision、人审、审批、客户消息、模型版本、证据来源、输出 hash 和发送渠道都可能成为重建事实的必要记录。
问题定义
AI 引入了记录治理的新难点：
- 业务系统保存了最终客户回复，但没有保存生成时使用的政策来源、prompt 和模型版本。
- Prompt log 被当作短期 debug 数据清理，后来无法证明客户收到的费用解释依据。
- RAG chunk 存在向量库中，但没有 record category、retention class 和 legal hold propagation。
- 客服 AI 摘要进入 system of record，却无法区分原始客户陈述和 AI 改写。
- Legal hold 覆盖某客户投诉，但供应商日志、eval sample、review queue 和 object store 未被保全。
- 为降低隐私风险删除了 prompt，但同时破坏了正在保全的电子证据。
核心问题是：AI 事件何时从技术日志变成记录对象，以及记录对象如何跨应用、模型、向量库、供应商和归档层保持一致治理。
核心原理/方法
先建立 AI record object taxonomy：
| 记录对象 | 示例 | 治理关注 |
|---|---|---|
| Interaction record | prompt、客户输入、员工输入、system instruction、response | 客户沟通、投诉、行为证据 |
| Retrieval record | query、retrieved chunk、source doc、rank、effective date | 事实依据、政策引用、版本 |
| Decision record | policy decision、model score、recommendation、reason code | 客户影响、模型治理、合规 |
| Action record | tool call、CRM write、refund、case closure、message sent | 系统写入、资金动作、责任链 |
| Review record | human review、approval、override、reason、evidence viewed | 控制证明、质量、独立性 |
| Governance record | eval result、incident、waiver、model/prompt release | 模型风险和控制有效性 |
| Derived record | summary、label、embedding、memory、feature、redacted copy | 来源、用途、保留和删除冲突 |
Retention schedule 不能只按应用系统定义，要按 record object + business context 定义。例如同样是 prompt，在内部草稿、客户可见回复、投诉处理、交易决策、销售建议、法律保全中的保留要求完全不同。
系统/架构模型
AI Event Capture SDK
-> Record Classification Service
-> Retention Policy Engine
-> Immutable / Audit-Trail Store
-> Legal Hold Service
-> Search & Review Workbench
-> eDiscovery / Regulator Exporter
-> Disposition Engine
-> Chain-of-Custody Ledger
关键组件：
| 组件 | 职责 |
|---|---|
| Event capture SDK | 在 prompt、RAG、tool、review、approval、output、send 等节点捕获结构化事件 |
| Classification service | 依据业务对象、客户影响、渠道、record type、privacy class 和 hold eligibility 分类 |
| Retention engine | 将记录映射到 retention schedule、authoritative copy、derived record policy 和 deletion rule |
| Immutable store | 对需保全或监管保存的记录提供不可篡改或 audit-trail 能力 |
| Legal hold service | 按 matter、custodian、customer、date range、record type、model version、channel 下发 hold |
| Search workbench | 支持 legal/compliance review、去重、redaction、privilege tagging 和 production set |
| Exporter | 生成监管或 eDiscovery 所需 metadata、hash manifest、chain-of-custody 和 load file |
| Disposition engine | 在无 active hold 时执行到期删除，并生成 disposition certificate |
架构重点是 close-to-event capture。事后用自然语言总结重建记录，无法满足可靠性、完整性和可复盘性要求。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| Under-retention vs over-retention | 过早删除会破坏证据；无限保存会增加隐私、泄露、诉讼和成本风险 |
| 原始记录 vs 派生记录 | 原始 prompt/输出提供事实基础；summary 和 embedding 也可能需要治理，但保留策略可不同 |
| 应用级分类 vs 对象级分类 | 应用级简单但粗糙；对象级能区分客户可见、内部 debug、监管记录和 legal hold eligibility |
| WORM / immutable vs audit-trail alternative | 高监管记录可能需要强不可篡改；其他记录可用可证明修改历史的审计轨迹 |
| 删除请求 vs legal hold | 有效 legal hold 通常应阻止删除，直到 hold release；系统要可证明冲突处理 |
| Vendor logs vs 内部 authoritative copy | 供应商日志不可完全依赖；关键记录应由内部捕获或有契约化 production 能力 |
AI retention 也要考虑成本。并非所有 token、trace 和临时向量都应永久保存；但任何影响客户、监管、资金、投诉或控制证明的记录，都要有明确分类和保留依据。
证据与控制
AI records 的控制要证明六件事：捕获、分类、保留、保全、出示、销毁。
| 控制 | 证据 |
|---|---|
| Capture | event schema、capture point、record completeness、source system、timestamp |
| Classification | record type、business domain、privacy class、retention class、hold eligibility |
| Retention | schedule mapping、authoritative copy、retention trigger、expiry、policy version |
| Legal hold | matter id、scope、custodian、systems、acknowledgement、propagation status |
| Production | search criteria、review decision、redaction log、metadata dictionary、hash manifest |
| Disposition | hold conflict check、approval、deletion job、exception、disposition certificate |
关键指标包括：unclassified AI record、missing event field、hold propagation failure、records beyond retention、records deleted under hold、export SLA、redaction defect、chain-of-custody gap。
金融零售/AI产品场景
客户费用投诉：客户称 AI 客服误导其错过退款期限。组织需要重建客户原话、AI prompt、retrieved policy、输出、客服修改、发送文本、policy version 和后续补救。
财富销售沟通：AI 生成 RM 邮件草稿。最终发送内容、approved claim、客户上下文、disclosure、审批和模型版本都可能需要保留以支持 conduct surveillance。
信用卡争议拒绝：AI 参与证据摘要和拒绝理由。争议记录应包括原始证据、AI 摘要、reviewer decision、tool action、客户通知和 case closure。
模型治理审计：监管或内部审计要求证明某次模型变更后控制仍有效。eval result、release approval、incident、waiver 和 corrective action 都属于治理记录。
反模式
- 把 AI prompt/output 全部归为 debug log，按短期技术日志清理。
- 永久保存所有 prompt，未分类、未最小化、未考虑隐私和诉讼暴露。
- 只保存最终答案，不保存 source、policy decision、tool trace 和人审。
- Legal hold 只覆盖主应用数据库，不覆盖向量库、对象存储、供应商日志、eval sample 和 review queue。
- 删除请求执行前不检查 active hold。
- eDiscovery export 只能导出截图或 PDF，缺少 metadata、hash 和 chain-of-custody。
- AI summary 覆盖原始客户陈述，导致事实来源混淆。
最终心智模型
AI 记录治理的核心不是“多保存日志”，而是“把影响客户、控制和法律义务的 AI 事件转成可分类、可保留、可保全、可出示、可销毁的记录对象”。记录架构必须从 AI workflow 设计阶段就嵌入，否则事后补证据会昂贵且不可信。
成熟架构能回答：某次 AI 输出是否构成记录，保存在哪里，保留多久，是否被 legal hold 覆盖，能否按范围检索和出示，何时可以删除，以及删除或保全的证据是什么。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。