AI Data Lifecycle Governance：来源-保留-删除
AI data lifecycle governance 是知道每个 AI 数据对象从哪里来、为什么用、被谁处理、进入了哪个 prompt 或工具、产生了什么输出、保留多久、何时删除、如何证明。AI 数据不只是训练数据，还包括知识库、检索片段、prompt、用户输入、工具结果、模型输出、反馈、日志、eval dataset 和治理证据。
AI Data Lifecycle Governance / Provenance / Retention 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_DATA_LIFECYCLE_GOVERNANCE_PROVENANCE_RETENTION_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将数据治理纳入 AI 风险管理 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 将数据、责任和持续改进纳入 AI management system |
| W3C PROV | https://www.w3.org/TR/prov-overview/ | 参考 provenance 的 entity、activity、agent 思维 |
| NIST Privacy Framework | https://www.nist.gov/privacy-framework | 参考隐私风险管理、数据处理和组织控制 |
| JSON Schema | https://json-schema.org/ | 为数据对象、日志、evidence object 建立结构约束 |
核心导读
AI data lifecycle governance 是知道每个 AI 数据对象从哪里来、为什么用、被谁处理、进入了哪个 prompt 或工具、产生了什么输出、保留多久、何时删除、如何证明。AI 数据不只是训练数据，还包括知识库、检索片段、prompt、用户输入、工具结果、模型输出、反馈、日志、eval dataset 和治理证据。
金融零售 AI 的数据治理难点在于：同一条客户或交易数据可能同时用于服务、风控、营销、投诉、模型评测和证据保留。没有生命周期治理，AI 会把数据最小化、保留、删除、权限和审计推向不可控。
问题定义
AI 扩大了数据生命周期的范围：
- 文档被切片、向量化、缓存和重排，原始来源与生成回答之间的链路容易断裂。
- 用户输入可能包含敏感信息，被写入日志、供应商系统或反馈集。
- 模型输出可能成为业务记录、客户承诺或后续训练数据。
- 删除请求需要覆盖原始数据、派生数据、索引、缓存、日志和证据。
- retention 既要满足隐私最小化，又要满足监管、审计和模型风险证据要求。
数据生命周期治理要回答：
| 问题 | 机制 |
|---|---|
| 数据从哪里来 | provenance、source registry、owner |
| 为什么可以使用 | purpose、legal basis、consent、policy |
| 如何被转换 | ingestion、chunking、embedding、prompt assembly |
| 谁访问和处理 | entitlement、agent/tool/service identity |
| 产生了什么派生对象 | output、feedback、eval sample、evidence |
| 保留多久并如何删除 | retention schedule、deletion workflow、proof |
核心原理与方法
AI 数据对象需要扩展分类：
| 数据对象 | 示例 | 治理关注 |
|---|---|---|
| Source Data | 客户资料、交易、政策、通话记录 | 权限、质量、目的、保留 |
| Knowledge Artifact | 文档 chunk、embedding、metadata | provenance、freshness、访问控制 |
| Prompt Data | system prompt、user input、retrieved context | 最小化、敏感信息、版本 |
| Tool Data | API response、case status、payment data | 权限、审计、保留 |
| Output Data | 回答、摘要、建议、结构化字段 | 业务记录、客户影响、质量 |
| Feedback Data | thumbs、override、QA label、人工修改 | 再利用目的、偏差、权限 |
| Evidence Data | trace、eval report、approval、incident | 完整性、不可抵赖、保留期限 |
W3C PROV 的 entity、activity、agent 思维可转化为：
| PROV 对象 | AI 对应 |
|---|---|
| Entity | 文档、chunk、prompt、output、tool result、evidence |
| Activity | ingestion、retrieval、generation、tool call、review、deletion |
| Agent | 用户、员工、AI service、模型供应商、审批者 |
系统与架构模型
AI data lifecycle architecture：
Source Registry
-> Data / Knowledge Onboarding
-> Provenance Capture
-> Prompt / Retrieval Assembly
-> Generation / Tool Use
-> Output / Feedback Management
-> Retention / Deletion / Evidence
关键组件：
| 组件 | 职责 |
|---|---|
| Source Registry | source id、owner、purpose、classification、retention、access rule |
| Provenance Graph | 连接 source、chunk、embedding、prompt、output、tool result 和 user |
| Policy Engine | purpose limitation、consent、jurisdiction、data minimization |
| Retention Engine | 按对象类型和义务计算保留期限 |
| Deletion Orchestrator | 删除原始、派生、索引、缓存和供应商副本 |
| Evidence Store | 保存必要的审计和模型风险证据 |
| Schema Registry | 约束日志、trace、evidence 和数据对象结构 |
Source-to-output trace：
Customer Record / Policy Document
-> Chunk / Metadata / Embedding
-> Retrieved Context
-> Prompt Instance
-> Model Output
-> Human Review / Tool Action
-> Business Artifact
-> Feedback / Evidence
关键机制与取舍
| 取舍 | 判断原则 |
|---|---|
| 数据最小化 vs 回答质量 | 高风险或敏感数据默认最小化，只在明确目的下扩大上下文 |
| 删除权 vs 证据保留 | 删除派生业务数据时需区分隐私请求、法定记录和审计证据 |
| 细粒度 provenance vs 成本 | 客户影响和受监管场景保留细粒度链路，低风险场景可聚合 |
| 日志完整性 vs 敏感信息暴露 | 日志应可追溯但脱敏，必要时采用分层访问 |
| 数据复用 vs 目的限制 | feedback 和输出再用于训练或评测前必须重新确认目的和权限 |
数据生命周期策略应按对象类型定义，而不是用单一保留期限覆盖所有 AI 数据。
| 对象 | 保留策略示例 |
|---|---|
| Prompt trace | 按风险等级和客户影响保留，敏感字段脱敏或加密 |
| Retrieved chunk | 保留 source id 和版本，必要时不保留全文 |
| Output | 若成为业务记录，遵循业务记录保留；否则按 AI 日志策略 |
| Feedback | 用于质量改进时记录目的和可再利用范围 |
| Eval dataset | 版本化、脱敏、记录来源和授权 |
| Evidence | 按监管、审计和模型风险要求保留 |
证据与控制
数据治理控制：
| 控制目标 | 控制活动 | 证据 |
|---|---|---|
| 确保来源可追溯 | 每个 chunk、prompt 和 output 关联 source id | provenance query |
| 遵守目的限制 | use case 与数据用途绑定，超范围阻断 | policy decision log |
| 执行最小化 | prompt assembly 前过滤不必要字段 | minimization test、trace |
| 控制访问 | 检索和工具调用继承用户/服务权限 | entitlement test、access log |
| 管理保留和删除 | 对原始和派生对象执行 retention/deletion | deletion certificate、retention report |
| 防止低质数据污染 | ingestion 质量检查和 freshness 校验 | quality report、rejected item log |
Audit query 示例：
- 某个客户回答使用了哪些 source、chunk、模型版本和工具结果。
- 某个被删除客户的数据是否仍存在于 embedding index、cache、日志或 eval set。
- 某个知识库文档更新后，哪些回答、eval 和业务工件可能受影响。
- 哪些 AI use case 使用了某类敏感数据，目的和保留期限是什么。
AI 产品与金融零售场景
以客户服务 RAG 为例：
| 生命周期阶段 | 治理设计 |
|---|---|
| Source onboarding | 政策文档、产品条款、FAQ、客户 case 分级登记 |
| Chunking | 保留 source id、版本、生效日期、适用地区和 owner |
| Retrieval | 按客户、员工权限、产品、地区和上下文过滤 |
| Prompt assembly | 只放入回答所需最小上下文，敏感字段脱敏 |
| Output | 客户可见回答与内部建议分开记录 |
| Feedback | 人工修改和客户反馈分类进入质量改进 |
| Retention/deletion | trace、output、evidence 按客户影响和监管要求分别保留 |
真实取舍：为了回答准确，系统希望保留更多上下文；为了隐私和安全，系统必须最小化。可行做法是分层 provenance：保留 source id、版本和控制结果作为长期证据，对敏感全文和用户输入采用更严格的保留和访问控制。
反模式
- 只治理训练数据，不治理 prompt、RAG、输出、反馈和证据。
- 向量库没有 source id、版本和删除链路。
- 日志保存完整敏感输入，后续成为新的隐私风险。
- 删除请求只删原始系统，不处理派生对象和供应商副本。
- 数据保留策略与 AI 风险等级、客户影响和监管义务无关。
- 用反馈数据改进模型，却没有目的、授权和偏差治理。
最终心智模型
AI 数据生命周期治理是 source-to-prompt-to-output-to-feedback-to-evidence 的控制系统。它把 provenance 作为解释和审计基础，把 retention/deletion 作为隐私和合规基础，把 minimization 和 access control 作为安全基础。成熟的 AI 数据治理不是让数据更多，而是让每个数据对象的来源、用途、变化、责任和去向都可证明。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。