AI Consent / Preference / Purpose-Bound Data Architecture 解读

面向对象: AI Product Architect / Platform PM / Senior BA / Privacy Architect / Data Governance Lead。 核心问题: AI 不能把“同意过条款”解释成任意数据复用。金融零售 AI 必须把 consent、preference、purpose limitation 变成运行时可执行、可撤销、可证明的产品和架构能力。 学习目标: 能设计 purpose catalog、consent event model、preference center、data-use policy、RAG/tool enforcement、withdrawal/re-consent lifecycle 和 audit evidence。

重要说明: 本文是学习与作品集材料, 不构成法律、合规、隐私、审计或监管意见。正式项目必须由 Legal、Privacy、Compliance、Security、Data Governance、Model Risk、Product 和 Operations 共同确认适用要求。

---

Source Anchors

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.

---

1. Thesis

AI consent architecture answers:

Can this AI capability use this data, for this person, in this channel,
for this purpose, at this time, with this model, tool, memory, log,
vendor and evidence boundary?

Privacy-by-design asks whether personal data is collected and protected responsibly. Consent / preference / purpose-bound data architecture makes the answer executable at runtime.

It connects purpose catalog, consent/preference events, legal basis, product terms, data classification, RAG filters, tool authorization, memory/log policy, withdrawal workflow and evidence dashboards.

---

2. Why It Matters

AI systems multiply data-use contexts. The same transaction can appear in customer service, fraud triage, marketing personalization, RM copilot, RAG search, eval sets, prompt logs, memory and vendor telemetry.

Traditional consent records often answer only whether a customer accepted terms, an employee acknowledged a policy, or a user opted into marketing.

Production AI needs finer answers:

---

3. Core Concepts

Important nuance: consent can be weak if bundled, vague, coercive, stale or hard to withdraw. It does not override security controls, fair treatment obligations, legal holds or customer harm controls. Employee AI may require workforce notice, role policy and monitoring boundaries. Purpose limitation must be enforced by systems, not only by prompt instruction.

---

4. Purpose Catalog

The purpose catalog is the product-language bridge between privacy policy, legal basis, data governance and AI runtime controls.

Purpose records need owner, risk tier, data classes, allowed channels, legal basis, consent requirement, retention, vendor boundary, eval allowance, evidence requirement and re-consent triggers.

---

5. Architecture Diagram

Customer / Employee UI
  -> consent and preference center
  -> consent event store
  -> purpose catalog + legal basis registry
  -> policy decision point
  -> AI orchestration layer
       -> RAG retriever with purpose and ACL filters
       -> tool gateway with scope and object checks
       -> memory service with write allowlist
       -> log/evidence service with retention policy
       -> vendor/model gateway with data-use constraints
  -> policy decision log
  -> evidence store and dashboards

Runtime decision:

identity + purpose + consent_state + preference_state + data_class
+ action + channel + model + vendor + object_scope + time
=> allow / deny / minimize / step_up / reconsent_required / human_review

Design principle:

The model can request data, but the policy plane decides whether the data, tool, memory and log use is allowed.

---

6. Consent Event Model

Minimum event fields:

Event sourcing is useful because consent is a history of what was offered, accepted, narrowed, renewed, withdrawn and enforced.

---

7. Financial Retail Case

Scenario: A mobile banking AI assistant helps a customer understand a card transaction and prepare a dispute.

Allowed flow:

1. Customer signs in with strong authentication.
2. Assistant explains it can read selected transactions for dispute support.
3. Customer grants purpose-specific access to the selected card and last 90 days of transactions.
4. RAG retrieves dispute policy documents filtered by region and product.
5. Tool gateway allows transactions.read.selected_account_90d.
6. Assistant drafts a dispute but cannot submit until customer confirms the exact transaction and claim.
7. Submission creates evidence with notice version, consent event, action hash and tool result.

Blocked flow:

• The same grant cannot be reused for marketing segmentation.
• The assistant cannot write persistent memory saying “customer likely fraud risk”.
• A new feature that sends transaction data to a new vendor requires change review and potentially re-consent.
• Withdrawal stops future AI access and triggers propagation to session, token, RAG cache and personalization store according to policy.

---

8. PM / BA / Architect Checklist

9. Code-Lite Experiment

Use this as a portfolio demo for a policy decision function.

request:
  purpose_id: payment_dispute_support
  action: transactions.read
  object_scope: {account_id: card_456, lookback_days: 90}
  ai_capability: dispute_assistant:v2
consent_state:
  status: granted
  scopes: [transactions.read.selected_account_90d, dispute.draft.create]
  expires_at: 2026-08-31T23:59:59Z
  notice_version: consent-dispute-v4

decision = policy.evaluate(request, consent_state, preference_state, data_policy)
if allow: issue purpose_bound_token(ttl=15m, scope=granted_scope)
if minimize: return masked_or_summarized_fields_only()
if reconsent_required: show_capability_change_notice()
if deny: deny_and_log(policy_reason)

Test cases: allow selected account read within 90 days; deny full customer 360 export; deny marketing after withdrawal; require re-consent for a new vendor; minimize logs with hashes and policy decisions instead of raw PAN or prompt payload.

---

10. Pitfalls

---

11. Interview Questions

1. How would you explain why consent is not a universal permission in financial AI?
2. How do you design a purpose catalog for customer service, marketing, RM copilot and open banking?
3. What fields belong in a consent/preference event schema?
4. How do you enforce purpose limitation in RAG and tool calls?
5. What happens when a customer withdraws consent while an AI workflow is running?
6. When does a new AI capability require re-consent?
7. How do you prove that AI did not use opted-out data for personalization?
8. How do you balance evidence retention with data minimization?

30 秒回答:

I treat consent as a runtime control, not a checkbox. For financial AI, every data use maps to a purpose, scope, subject, channel, time window, capability version and evidence record. The policy layer enforces that state across RAG, tools, memory, logs and vendors.

2 分钟回答:

I would start with a purpose catalog and a consent/preference event model. Each AI capability declares purpose, data classes, allowed actions, legal basis, consent requirement and re-consent triggers. At runtime, the orchestration layer calls a policy decision point before retrieval, tool use, memory write or logging. The decision uses identity, purpose, consent state, preference state, object scope, expiry, vendor and risk tier. Withdrawal propagates to token revocation, session controls, RAG tombstones, personalization suppression and audit evidence, so the system can prove what was allowed, denied, minimized, withdrawn or re-consented.