AI Consent / Preference / Purpose-Bound Data Architecture Playbook

适用对象: 金融零售 AI Product Manager、Senior BA、Product Architect、Privacy Architect、Data Governance Lead、Security Architect、Model Risk、Compliance Product Owner。 核心问题: 如何把客户和员工的 consent、preference、purpose limitation 从政策语言变成 AI 产品和运行时架构。 重点边界: 本 playbook 不是泛泛的 privacy-by-design。它聚焦 consent / preference / purpose 在 AI RAG、tool、memory、log、vendor、open banking、客户 UX 和证据链中的执行。

重要说明: 本文是学习、作品集和架构训练材料, 不构成法律、隐私、合规、审计、模型风险管理或监管意见。正式项目必须由 Legal、Privacy、Compliance、Security、Data Governance、Model Risk、Product、Operations、Customer Experience 和业务责任人共同确认适用法规、合同、控制和证据要求。

---

1. Executive Framing

AI consent architecture 的目标不是“多弹一个同意框”。它的目标是让组织能在运行时回答并证明:

This AI use of this data is allowed for this subject,
under this purpose, scope, channel, legal basis, preference,
expiry, model, tool, vendor and evidence boundary.

金融零售 AI 的高风险来自 context expansion:

• 客户为客服提供的数据可能被营销系统误用。
• 员工在 RM copilot 中看到的客户资料可能被写入长期 memory。
• 开放银行授权数据可能被内部 AI enrichment 重新利用。
• RAG index 可能继续保留已撤销授权的文档片段。
• Prompt log、eval sample、feedback queue 和 vendor telemetry 可能成为隐性副本。

高级判断:

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.

本 playbook 的输出物:

• purpose taxonomy
• consent/preference event schema
• preference center capability map
• runtime enforcement architecture
• RAG/tool/data/memory/log controls
• withdrawal and re-consent lifecycle
• dashboards and KRIs
• RACI and operating model
• financial retail examples
• templates, 30-day lab and interview answers

---

2. Source Anchors

以下官方来源作为概念和控制设计锚点。访问日期按 2026-06-30 记录。

Standards-to-artifact:

---

3. Consent Architecture Is Not Generic Privacy-by-Design

关键定位:

• Consent 是授权意图和客户控制的一部分, 不是万能法律依据。
• Preference 是持续产品状态, 不只是 marketing unsubscribe。
• Purpose limitation 必须进入 policy engine、token、retrieval、tool、memory 和 logging。
• Evidence 是客户信任、审计和事故复盘的生产资产。

---

4. Purpose Taxonomy

Purpose taxonomy 是 consent architecture 的根。没有 purpose taxonomy, 团队只能说“AI uses customer data”, 无法表达为什么、边界在哪里、何时必须阻断。

4.1 Purpose Levels

4.2 Financial Retail Purpose Catalog

4.3 Purpose Record Fields

4.4 Purpose Compatibility Matrix

---

5. Consent, Preference and Legal Basis Model

5.1 Distinctions

5.2 Consent Is Not a Universal Permission

In financial AI, consent does not mean:

• all customer data can be used for all AI features.
• future AI capabilities inherit old consent automatically.
• product terms can silently expand model training or vendor use.
• opt-in overrides security, fairness, legal hold or complaint obligations.
• a preference toggle replaces purpose limitation.

Mature interpretation:

• Use consent where it is the right mechanism.
• Use legal basis and notice where consent is not appropriate.
• Use preferences to give meaningful control.
• Use product terms and in-context disclosure to prevent surprise.
• Use runtime enforcement to make choices real.

5.3 Preference Categories

5.4 Consent State Machine

not_present -> presented -> granted -> active -> narrowed
-> expired -> withdrawn -> superseded_by_new_version -> reconsent_required

Transitions must be event-driven. A CRM field update is not enough if active sessions, cached tokens, vector indexes or campaign audiences keep using stale state.

---

6. Consent and Preference Event Schema

6.1 Event Envelope

6.2 Consent Fields

6.3 Preference and Evidence Fields

6.4 Example Event

{
  "event_type": "consent_granted",
  "subject_type": "customer",
  "subject_id": "cust_8f3a",
  "channel": "mobile_app",
  "purpose_id": "payment_dispute_support",
  "scope_id": "transactions.read.selected_account_90d",
  "object_scope": {"account_id": "card_456", "lookback_days": 90},
  "notice_version": "notice-dispute-ai-v4",
  "capability_id": "dispute_assistant",
  "capability_version": "v2.3",
  "expires_at": "2026-08-31T23:59:59Z",
  "model_boundary": "internal_model_gateway_no_training",
  "withdrawal_effect": ["stop_future_use", "invalidate_tokens", "purge_session_cache"],
  "evidence_ref": "evd_9217"
}

---

7. Preference Center Product Architecture

7.1 Capability Map

7.2 UX Principles

7.3 Customer Copy Patterns

Grant:

Allow the AI assistant to read transactions from this card for the last 90 days
so it can help prepare your dispute. It cannot submit the dispute or use this
permission for marketing. You can withdraw this permission in Settings.

Withdrawal:

Withdrawing this permission stops future AI access for this dispute support
purpose. We may retain records needed to manage your dispute, security,
complaints or legal obligations.

Capability change:

This assistant can now attach merchant evidence to your dispute draft.
Because this changes what data the AI can use, please review and confirm.

---

8. Runtime Enforcement Architecture

8.1 Reference Architecture

User / Employee / Third Party
  -> channel app or API
  -> identity and authentication
  -> consent and preference service
  -> purpose catalog and legal basis registry
  -> policy decision point
  -> AI orchestrator
       -> prompt assembly service
       -> RAG retrieval gateway
       -> tool gateway
       -> memory service
       -> logging and evidence service
       -> vendor/model gateway
  -> policy decision log
  -> evidence store
  -> dashboards, alerts, recertification

8.2 Runtime Decision Inputs and Outputs

8.3 Enforcement Locations

8.4 Policy Pseudocode

function evaluate_ai_data_use(request):
  purpose = purpose_catalog.get(request.purpose_id)
  consent = consent_store.current(request.subject_id, request.purpose_id)
  preference = preference_store.current(request.subject_id)
  data_policy = data_policy_store.get(request.data_class, request.action)

  if purpose.status != "approved": return deny("purpose_not_approved")
  if request.action not in purpose.allowed_ai_actions: return deny("action_not_allowed")
  if consent.required and consent.status != "granted": return reconsent_required("missing_consent")
  if consent.expires_at < now(): return reconsent_required("consent_expired")
  if preference.blocks(request.action, request.channel, request.purpose_id): return deny("preference_block")
  if request.object_scope exceeds consent.scope: return deny("scope_exceeded")
  if data_policy.requires_minimization: return minimize(data_policy.allowed_fields)
  if purpose.high_risk_action(request.action): return step_up("confirmation_required")
  return allow("policy_pass")

---

9. RAG, Tool, Data, Memory and Log Controls

9.1 RAG Controls

RAG corpus manifest fields:

9.2 Tool Controls

Tool gateway checks:

• token audience targets this tool.
• purpose matches granted purpose.
• operation is within consent and role.
• account, customer, transaction or case is in scope.
• preference does not block channel/use.
• consent, token and approval are active.
• high-impact action has confirmation/approval.
• parameters are allowlisted, typed and rate-limited.
• evidence log captures decision and outcome.

9.3 Data and Memory Controls

Memory rule:

No AI memory write unless purpose allows it, data class permits it,
user/employee controls support it, retention is defined,
and deletion/withdrawal propagation is implemented.

9.4 Logging Controls

Do not default to storing full prompt, completion, tool response and raw identifiers in a general observability platform. Evidence should be deliberate, classified and access-controlled.

---

10. Withdrawal, Expiry and Re-Consent Lifecycle

10.1 Withdrawal Flow

User withdraws consent or changes preference
  -> event written to consent/preference store
  -> projection updates current state
  -> policy cache invalidated
  -> active sessions and tokens revoked or narrowed
  -> RAG cache/index receives tombstone or suppression event
  -> tools receive suppression/update event
  -> marketing/recommender audiences refreshed
  -> memory store deletes or disables entries as policy requires
  -> evidence record created
  -> customer/employee confirmation shown

10.2 Withdrawal Effects

10.3 Re-Consent Triggers

Re-consent UX must explain the change, show old vs new scope, avoid forced bundling, preserve evidence, respect previous withdrawal and update runtime state immediately.

---

11. Dashboards and KRIs

11.1 Product Dashboard

11.2 Control Dashboard

11.3 Board / Executive View

---

12. RACI

Legend: R = responsible, A = accountable, C = consulted.

---

13. Financial Retail Examples

Cross-case lesson: service, advice, marketing and data sharing may all involve the same customer record, but they are different purposes with different consent, preference, evidence and runtime controls.

---

14. Templates

14.1 Purpose Catalog Template

14.2 Runtime Policy Decision Table

14.3 RAG and Tool Checklists

14.4 Withdrawal Runbook Card

14.5 Evidence Query Examples

SELECT
  pd.policy_decision_id,
  pd.interaction_id,
  pd.purpose_id,
  pd.action,
  ce.event_id AS consent_event_id,
  ce.status,
  ce.notice_version,
  pd.decision,
  pd.reason_code
FROM ai_policy_decision pd
LEFT JOIN consent_event_current ce
  ON pd.subject_id = ce.subject_id
 AND pd.purpose_id = ce.purpose_id
WHERE pd.interaction_id = :interaction_id;

---

15. 30-Day Lab

目标: 30 天内产出一个可展示的 consent / preference / purpose-bound AI data architecture portfolio pack。

---

16. Interview Answers

Q1: 为什么 consent 不是 AI 的万能许可?

30 秒版本:

Consent 只能覆盖特定目的、范围、时间和告知内容。金融 AI 里, 客户同意客服读取交易, 不等于同意营销、训练、长期记忆或新供应商使用这些数据。真正的架构要把 consent 和 purpose 绑定到 RAG、tool、memory、log 和 vendor controls。

2 分钟版本:

我会先区分 consent、preference、legal basis 和 runtime authorization。Purpose catalog 记录每个 AI capability 的允许用途、数据类别、动作、scope、expiry 和 re-consent triggers。运行时由 policy engine 检查 consent state、preference state、data class、object scope、model/vendor 和 action。旧 consent 不会自动覆盖新功能, 撤销也能传播到 tokens、RAG、tools、memory 和 campaigns。

Q2: 如何设计 purpose catalog?

30 秒版本:

Purpose catalog 要把业务语言转成可执行策略。每个 purpose 记录业务价值、允许 AI actions、禁止用途、数据类别、法律基础、consent requirement、preference controls、expiry、withdrawal effect、re-consent triggers 和 evidence owner。

2 分钟版本:

我会从用户旅程和业务 outcome 出发。Customer service, payment dispute, RM prep, marketing personalization, open banking 都是不同 purpose。每个 purpose 定义 allowed actions、data classes、scope、channels、legal basis、consent requirement、preference controls 和 evidence owner。最后把 purpose ID 放进 policy engine、RAG metadata、tool policy、log schema 和 dashboard。

Q3: consent/preference event schema 必须有哪些字段?

30 秒版本:

至少包括 event type、subject、actor、channel、purpose、scope、status、notice version、legal basis reference、capability version、effective/expiry、withdrawal effect 和 evidence reference。

2 分钟版本:

我会采用 event-sourcing 思路, 因为 consent 是 grant、narrow、withdraw、expire、supersede、re-consent 的历史。Envelope 记录 subject、actor、channel、tenant、jurisdiction 和 correlation ID。Consent 字段记录 purpose、scope、data class、object scope、notice/capability version、model/vendor boundary、effective/expiry 和 withdrawal effect。Preference 字段记录 type、value、source 和 propagation targets。Evidence 字段记录 UI snapshot、text hash、auth context、API hash 和 policy decision ID。

Q4: 如何在 RAG 中执行 purpose limitation?

30 秒版本:

RAG 必须在 retrieval time 做 purpose、ACL、consent、preference、freshness 和 data-class filtering, 不能先检索再让模型自觉不说。每次检索要记录 corpus、filter policy、excluded reason 和 retrieved chunk IDs。

2 分钟版本:

我会给每个 corpus 建 manifest, 记录 source system、allowed purposes、data classes、consent dependency、access filters、retention 和 deletion propagation。检索时, retriever 用 identity、purpose、current consent/preference state、object scope 和 policy version 过滤候选 chunk。被排除的 chunk 记录 reason。撤销后触发 tombstone 或 targeted purge, 并用 negative tests 证明 withdrawn data 不会再被检索到。

Q5: 如何处理 withdrawal?

30 秒版本:

Withdrawal 不是只更新一个偏好字段。它要写事件、更新状态投影、失效 policy cache、撤销 token/session、通知 RAG/tool/memory/campaign/vendor, 并生成传播和验证证据。

2 分钟版本:

我会设计 withdrawal propagation runbook。写入 event 后更新 current-state projection, 让 policy engine 立即看到新状态。然后撤销或缩小 active tokens and sessions, 向 RAG、tool gateway、memory、campaign、vendor gateway 和 evidence services 发送 propagation task。最后执行 purge、tombstone、suppression 或 retain-evidence action, 并用 synthetic calls 和 dashboard 验证被撤销的 data use 已被拒绝。

Q6: 什么时候需要 re-consent?

30 秒版本:

当 purpose、data class、action、vendor、model behavior、retention、channel 或 open banking scope 发生 material change 时, 通常需要 re-consent 或至少 legal/privacy review。

2 分钟版本:

我会把 re-consent triggers 写入 purpose catalog 和 capability registry。典型触发包括: 从客服扩展到营销, 新增 credit bureau data, draft-only 变成 submit-capable, 引入外部模型, 启用 AI memory, 延长 retention, 跨渠道复用授权, 或开放银行 scope 扩大。产品上展示 old vs new scope, 解释变化和后果, 允许拒绝, 并把新 notice/capability version 写入 evidence。

Q7: 如何证明没有使用 opted-out data 做 personalization?

30 秒版本:

需要 suppression-aware feature pipeline、policy decision logs、campaign inclusion evidence、recommender input manifest 和 negative tests。不能只说“我们尊重 opt-out”。

2 分钟版本:

我会让 marketing preference event 传播到 campaign、feature store、recommender、AI content generator 和 analytics。每次 personalized offer 生成时记录 purpose、preference snapshot、feature set version、suppression list version、policy decision ID 和 inclusion reason。对 opted-out 客户做 negative test: 他们不应出现在 audience、feature retrieval、prompt context 或 vendor payload 中。

Q8: Open banking 授权数据能否用于内部 AI?

30 秒版本:

不能自动使用。开放银行授权通常是特定第三方、数据范围、期限和目的的授权。内部 AI secondary use 必须单独做 purpose compatibility、legal/privacy review、notice/consent 和 runtime enforcement。

2 分钟版本:

我会把 open banking authorization 当成独立 purpose: open_banking_data_sharing。它允许 API 在客户授权范围内向指定第三方共享数据, 不代表银行内部可以训练模型、营销或 enrichment。Token service 和 API gateway 按 account/data/time/third-party scope 执行; withdrawal 立即阻止未来访问。内部 AI 若解释授权状态或做安全监控, 必须使用自己的合法目的和最小化数据。

---

17. Production Readiness Checklist

• 每个 AI capability 有 approved purpose catalog entry。
• Consent、preference、legal basis 和 notice version 能被区分和查询。
• Consent/preference event schema 支持 grant、withdraw、expire、supersede、re-consent。
• Preference center 能修改 AI、marketing、channel、memory 和 data sharing choices。
• Runtime policy engine 在 RAG、tool、memory、log、vendor 前执行。
• RAG corpus manifest 包含 allowed purposes、consent dependency、ACL 和 deletion propagation。
• Tool gateway 强制 audience、purpose、scope、object、expiry 和 step-up。
• Memory write 使用 allowlist、TTL、user controls 和 deletion propagation。
• Logs 使用 manifest/hash/policy decision, 高风险 payload 进入受控 evidence vault。
• Withdrawal runbook 演练过 token、session、RAG、tool、memory、campaign、vendor propagation。
• Re-consent triggers 和 capability versioning 已接入 release gate。
• Dashboard 覆盖 grant、withdrawal、purpose mismatch、expired usage、propagation latency 和 evidence completeness。
• RACI 明确 PM、BA、Architect、Privacy、Legal、Security、Data Governance、Model Risk 和 Ops 责任。
• 四类案例至少完成一个端到端设计: customer service、RM copilot、marketing personalization、open banking。

18. Closing View

金融零售 AI 的 consent / preference / purpose-bound data architecture 成熟度, 决定了客户控制是否真实、产品承诺是否可信、监管证据是否可查、AI 变更是否可控。

真正的目标不是收集更多同意, 而是让每一次 AI 数据使用都能被设计、限制、执行、撤销、解释和证明。