AI Consent / Preference：目的绑定数据架构
在 AI 架构中，consent 和 preference 不是前端勾选框，而是运行时数据边界。金融零售 AI 会在 prompt、RAG、工具调用、memory、personalization、training/eval、日志和人工复核中反复使用客户数据；如果 purpose 没有被系统执行，所谓授权会变成一次性同意被无限复用。
AI Consent / Preference / Purpose-Bound Data Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_CONSENT_PREFERENCE_PURPOSE_BOUND_DATA_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST Privacy Framework | https://www.nist.gov/privacy-framework | 用 privacy risk management 语言组织 purpose、control、communication 和 evidence。 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 把 consent enforcement 纳入 AI risk lifecycle。 |
| FTC Safeguards Rule | https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know | 作为金融客户信息保护、访问控制、服务提供商监督和安全计划锚点。 |
| CFPB Personal Financial Data Rights | https://www.consumerfinance.gov/personal-financial-data-rights/ | 用于客户授权、数据访问、撤销和开放银行数据权利的产品架构讨论。 |
| ISO/IEC 42001 | https://www.iso.org/standard/42001 | 用 AI management system 的思路落地政策、角色、监控、变更和持续改进。 |
Consent is not a universal permission. In financial AI, it must be purpose-specific, revocable, evidence-backed, and coordinated with legal basis, product terms, privacy, security, customer trust, and operational controls.
核心导读
在 AI 架构中，consent 和 preference 不是前端勾选框，而是运行时数据边界。金融零售 AI 会在 prompt、RAG、工具调用、memory、personalization、training/eval、日志和人工复核中反复使用客户数据；如果 purpose 没有被系统执行，所谓授权会变成一次性同意被无限复用。
Purpose-bound data architecture 的目标是：客户数据只能在被允许的目的、产品、渠道、区域、供应商和保留期限内使用；撤回、偏好变更和新用途必须能传播到 AI workflow 的所有数据路径。
问题定义
AI 产品放大了数据用途漂移：
- 客户授权账户数据用于预算洞察，团队随后把同一数据用于信用营销分群。
- 客服助手把一次会话中的敏感信息写入长期 memory，之后在无关场景中使用。
- RAG 系统把投诉、CRM note 和交易数据混入知识库，未区分目的和保留规则。
- 开放银行数据进入 feature store 后，被多个模型复用，无法追踪 consent scope。
- 客户撤回授权后，session cache、向量索引、eval sample 和供应商日志仍保留数据。
- Preference center 只影响营销触达，不影响 AI personalization、next best action 和员工助手。
问题不是“有没有同意”，而是“同意的目的、范围、期限、撤回和证据是否在运行时被强制执行”。
核心原理/方法
Purpose catalog 是基础。它要把业务用途转成可执行 policy，而不是法律文本附件：
| Purpose | 允许用途示例 | 不应自动扩展到 |
|---|---|---|
| Account servicing | 回答余额、交易、费用、争议和服务请求 | 个性化营销或模型训练 |
| Fraud prevention | 风险信号、异常检测、交易保护 | 交叉销售分群 |
| Personal finance insights | 消费分类、预算提醒、现金流洞察 | 信用额度提升营销 |
| Product recommendation | 在明确授权和规则下推荐产品 | 高风险投资建议或不适当销售 |
| AI quality evaluation | 抽样评估输出质量和安全 | 无限制长期训练 |
| Regulatory / dispute handling | 投诉、争议、法律保全、审计证据 | 体验优化之外的二次使用 |
Consent event model 至少要包含：
| 字段 | 说明 |
|---|---|
| Subject | 客户、账户、家庭、商户、员工或代理关系 |
| Data scope | 数据类别、来源、账户、时间范围、敏感等级 |
| Purpose id | 标准化用途，不是自由文本 |
| Channel / product | 适用产品、渠道、业务流程 |
| Processor / vendor | 内部系统、供应商、子处理方、区域 |
| Effective period | 生效、到期、撤回、重新授权 |
| Evidence | 文案版本、展示位置、客户动作、语言、时间戳 |
| Propagation state | 下游系统是否已执行撤回或偏好变更 |
Preference 与 consent 不同。Preference 可表达客户不想接收某类触达或不想使用某项 personalization；consent/legal basis 决定是否可处理数据。架构上两者都需要进入 policy decision。
系统/架构模型
Purpose Catalog
-> Consent & Preference Ledger
-> Data Classification / Lineage
-> Purpose Policy Engine
-> Data Access Broker
-> RAG / Memory / Feature Store Gateway
-> Model / Tool Gateway
-> Withdrawal Propagation Service
-> Evidence & Audit Ledger
关键组件：
| 组件 | 职责 |
|---|---|
| Purpose catalog | 维护 purpose id、allowed data、allowed processors、retention、region、prohibited reuse |
| Consent ledger | 保存授权、撤回、重新授权、偏好和证据版本 |
| Data access broker | 在数据读取时校验 subject、purpose、product、channel 和 consent state |
| RAG gateway | 对 corpus、chunk、query 和 retrieval result 执行 purpose filter 和权限过滤 |
| Memory service | 限制可写入 memory 的内容、期限、用途和撤回处理 |
| Model/tool gateway | 在 prompt assembly、tool payload、vendor call 前执行 purpose policy |
| Withdrawal propagation | 将撤回传播到 cache、token、index、feature、eval、日志和供应商 |
| Evidence ledger | 记录每次 policy decision、数据访问、拒绝、撤回和传播状态 |
架构要让 purpose 在运行时可判定。仅在需求文档中说明“数据只用于服务”无法防止模型链路复用。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| 粗粒度授权 vs 细粒度目的 | 粗粒度 UX 简单但风险高；细粒度更可控但可能增加客户负担。可用分层 purpose 和清晰文案平衡 |
| 中央 consent ledger vs 系统内偏好 | 中央 ledger 保证一致性；系统本地缓存提升性能。必须有版本、失效和同步证据 |
| Personalization vs 最小化 | 个性化提高体验，但应限制 memory、feature 和 prompt 中的敏感信息 |
| 撤回即时性 vs 技术传播 | 客户期望立即生效；后台索引和供应商日志可能需要策略化传播和证明 |
| Re-consent vs 变更通知 | 新目的、新供应商、新数据类别或新自动化影响通常不能只靠静默更新 |
| 训练/eval 使用 vs 客户信任 | 质量改进有价值，但应使用最小化、脱敏、抽样、保留期限和 purpose-specific control |
对于 AI 产品，最容易被忽视的是 derived data。模型生成的标签、风险解释、客户偏好推断和 summary 可能仍与原始 purpose 绑定，不能因为“是 AI 生成的”就脱离限制。
证据与控制
Purpose-bound 架构需要证明每次数据使用都有合法/授权/政策基础：
| 证据对象 | 关键字段 |
|---|---|
| Consent event | subject、data scope、purpose、文案版本、客户动作、时间、channel |
| Preference event | opt-in/out、类别、渠道、产品、effective time、source |
| Policy decision | purpose id、data class、requesting system、allow/deny、reason、policy version |
| Data lineage | source、derived object、feature、RAG chunk、memory item、eval sample、retention class |
| Withdrawal propagation | downstream target、state、timestamp、exception、manual remediation |
| Vendor processing record | processor、region、data category、purpose、subprocessor、return/delete evidence |
| Audit replay | 某次 AI 输出使用了哪些数据、为何允许、客户当时的 consent/preference 状态 |
控制指标包括：purpose-denied access、missing purpose id、stale consent cache、withdrawal propagation lag、unauthorized derived data、memory write rejection、vendor purpose mismatch、preference violation complaint。
金融零售/AI产品场景
开放银行个人财务助手：客户授权交易数据用于预算洞察，不代表可用于信用营销。AI gateway 应将 account insight、marketing recommendation、credit eligibility 分成不同 purpose，并在撤回后停止未来访问和 personalization。
信用卡客服助手：客服可用客户交易和争议资料处理服务请求，但不能把敏感投诉内容写入长期 memory 用于后续销售话术。
财富内容推荐：客户偏好“不要接收高风险产品营销”应影响 next best action、RM copilot、campaign copy 和 recommendation ranking，而不只是短信退订。
欺诈防控：欺诈目的可使用更广的风险数据，但输出和衍生标签仍要限制访问、保留和二次用途，避免被营销或不相关服务复用。
反模式
- 把 consent 当成一次性全局同意，后续所有 AI 用途都默认可用。
- Preference center 只控制营销渠道，不控制 AI personalization、员工助手和模型特征。
- RAG corpus 混合政策、CRM、投诉、交易和员工笔记，缺少 purpose metadata。
- 客户撤回后只停止 API 拉取，不处理缓存、向量索引、eval set、memory 和供应商日志。
- 用“AI 生成标签不是原始数据”规避 purpose 和 privacy 控制。
- 新供应商或跨境处理上线时没有 re-consent / change review / data-use policy 更新。
- 审计只能看到同意记录，无法证明某次输出为何允许使用某些数据。
最终心智模型
Consent 是证据，purpose 是边界，policy enforcement 才是控制。金融零售 AI 的数据治理不能停在隐私声明和前端勾选框，而要把目的限制嵌入 prompt、RAG、memory、tool、model、eval、日志和供应商路径。
成熟架构能回答：某次 AI 输出用了哪些客户数据、这些数据为何能用于该目的、客户当时的偏好和授权是什么、撤回会传播到哪里、衍生数据如何处理。如果回答依赖人工解释而不是系统事件，purpose-bound data 还没有真正落地。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。