AI 合成数据治理架构：Synthetic Data Governance / Privacy-Utility-Fidelity Architecture

Date: 2026-06-30
Status: evergreen
Audience: experienced CBAP / financial retail PM / data product architect / AI architect / privacy-risk partner
Output: advanced architecture note, governance model, release gate design, ADR draft, interview-ready narrative

---

Why synthetic data governance matters

Synthetic data 不是“假数据”, 也不是把真实客户数据丢给生成器后自动得到安全资产。对金融零售 AI 来说, synthetic data 是一种受治理的数据产品:

Synthetic data product = approved purpose + source permission + generation method + privacy attack evidence + utility/fidelity score + allowed-use license + release gate.

它的价值在于让团队在不无限复制敏感数据的情况下, 支持 AI 开发、流程测试、边界场景扩展、员工训练和供应商 PoC。但它也会引入新的风险:

高级 PM / BA / Architect 的关键判断不是“能不能生成一批数据”, 而是:

Which business decision can this synthetic dataset support,
what real data permissions authorize its creation,
what privacy attacks has it survived,
what utility and fidelity evidence proves it is fit for use,
and what license prevents misuse after release?

本文刻意不重复四个相邻主题:

• Synthetic user simulation 关注 persona / scenario / journey lab; 本文关注 synthetic dataset 作为数据产品的治理和发布。
• Privacy clean room 关注多方数据协作和受控计算; 本文关注企业内部或受控供应商场景中的合成数据资产。
• Differential privacy 关注数学隐私预算; 本文把 DP 视为可选控制之一, 不把它当成全部方案。
• Eval dataset lifecycle 关注 eval set 的版本、标签和回归治理; 本文关注 synthetic data 是否可被释放、用于何种目的、证据是否充分。

---

Concept diagram

flowchart TB
  A[Use-case intake<br/>purpose, users, risk tier,<br/>allowed decision] --> B[Source permission gate]
  B --> C[Source data registry<br/>classification, consent, contract,<br/>lineage, retention, owner]
  C --> D[Generation plan<br/>method, prompts, rules, model,<br/>sampling, constraints]
  D --> E[Generator risk review<br/>memorization, rare cases,<br/>prompt leakage, vendor boundary]
  E --> F[Synthetic dataset build]
  F --> G[Privacy attack workbench<br/>membership inference,<br/>model inversion, linkage,<br/>nearest-neighbor, canary tests]
  F --> H[Utility and fidelity lab<br/>task performance, distribution,<br/>business rules, SME review]
  F --> I[Representativeness and bias review<br/>coverage, subgroup error,<br/>amplification, missingness]
  G --> J[Data card and evidence packet]
  H --> J
  I --> J
  J --> K{Release gate}
  K -->|Reject| D
  K -->|Limited release| L[Allowed-use license<br/>scope, users, prohibited uses,<br/>expiry, retention, watermark]
  K -->|Promote| M[Dataset catalog<br/>provenance, version,<br/>access control, monitoring]
  M --> N[Downstream use<br/>RAG, Agent, Copilot,<br/>Eval, training, QA, sandbox]
  N --> O[Usage telemetry and incident feedback]
  O --> A

核心闭环:

business purpose
  -> source permission
  -> governed generation
  -> privacy / utility / fidelity / bias evidence
  -> allowed-use release
  -> monitored downstream use
  -> renewal, restriction or retirement

---

Core architecture model

1. Use-case intake as the first control

Synthetic data 治理从 intake 开始, 不是从生成器开始。一个成熟 intake 要把“为什么需要合成数据”写清楚。

Intake 的产品原则:

• 不能用一个 synthetic dataset 服务无限多目的。
• 高风险用途必须把 allowed use 写成 license, 不是写在邮件里。
• 如果真实源数据没有权限支持某用途, 合成后也不自动获得该用途权限。

2. Source permission and lineage layer

Synthetic data 的合法性、合规性和可解释性取决于 source data permission。架构上应建立 source permission matrix。

Source permission 的关键认知:

Synthetic output inherits constraints from source data unless a reviewed governance decision narrows, transforms and re-licenses the output.

3. Generation architecture patterns

不同生成方式对应不同风险和证据需求。

生成器本身也要治理:

• 记录 generator model、version、prompt、seed、rules、parameters、source sample window。
• 对 LLM 生成场景, 禁止把敏感 source 原文直接放入不受控 vendor prompt。
• 对高风险数据, 使用 isolated generation environment、short-lived workspace、access logging 和 artifact cleanup。
• 对重复生成任务, 建立 prompt/rule registry, 避免手工脚本成为隐形数据处理系统。

4. Data card and license layer

每个可释放 synthetic dataset 都应有 data card, 并附带 allowed-use license。

---

Privacy-utility-fidelity measurement model

Synthetic data release 必须同时测 privacy、utility、fidelity。只测一个维度会导致错误决策。

1. Three-axis model

Privacy: can an attacker infer a real person, record, document, call or transaction?
Utility: does the dataset support the approved task?
Fidelity: does it preserve the relevant structure of the target domain without copying protected facts?

2. Privacy attack testing

高风险 synthetic data 至少应覆盖以下测试。

3. Utility/fidelity scoring

建议用多维 scorecard, 不把分数压成单一平均值。

4. Representativeness without copying reality

Representativeness 不是把真实分布完整复制。金融零售 synthetic data 要处理三种 tension:

---

Allowed-use and release gate design

1. Allowed-use license

Synthetic dataset release 应像 API scope 一样有 license。

2. Release gate levels

Gate 的关键纪律:

• 低风险 release 不能自动升级为高风险用途。
• G3/G4 必须有 residual risk owner, expiry 和 reopen trigger。
• 如果 utility 高但 privacy attack 失败, 不能通过“业务价值大”绕过 gate; 只能缩小用途、重生成、加控制或拒绝。
• 如果 privacy 强但 utility 不足, 不能当作模型训练或 validation 数据, 只能作为 demo/mock 或流程测试数据。

---

Financial retail scenarios

1. AML typology training

目标是训练 analyst 识别 typology, 不是复制真实 SAR case。

2. KYC document testing

目标是测试 document ingestion、OCR、field extraction、exception routing。

3. Credit model scenario augmentation

目标是扩展边界场景, 不替代真实 model validation。

4. Payment fraud simulation

目标是压测 fraud rules、agent alert triage、payment warning UX。

5. Contact center transcript generation

目标是生成受控 transcript, 用于 copilot QA、intent classification、agent training。

6. Complaint analytics

目标是扩展 complaint themes 和 root-cause analytics coverage, 不是制造虚假投诉指标。

---

Metrics/control/evidence model

1. Metrics

2. Control model

3. Evidence packet

上线或释放时至少保留:

• use-case intake and risk tier
• source permission matrix and data classification
• generation plan, generator version, prompts/rules, source window
• privacy attack report and exceptions
• utility/fidelity scorecard
• bias/coverage review
• data card and allowed-use license
• watermark/provenance evidence
• approver list, residual risk owner, expiry date
• retention/deletion requirements
• downstream access logs and monitoring plan

---

Anti-patterns and failure modes

---

Architecture mapping to RAG / Agent / Copilot / Eval / Governance

关键架构原则:

Synthetic data may enter AI workflows only through typed, versioned, licensed datasets.
It should never be an invisible folder of files copied into prompts, notebooks or vendor sandboxes.

---

ADR draft

---

Interview answer

30秒版本

我会把 synthetic data 当成受治理的数据产品, 而不是“假数据”。核心架构是 use-case intake、source permission、generation risk review、privacy attack testing、utility/fidelity measurement、bias/coverage review、data card、allowed-use license、watermark/provenance、retention 和 release gate。这样既能支持 AML、KYC、信贷、欺诈、客服和投诉 AI 场景, 又不会把合成数据误用成无限制训练或外发资产。

2分钟版本

在金融零售里, synthetic data 的价值是降低真实客户数据在开发、测试、训练和供应商 PoC 中的暴露, 同时扩展长尾场景。但风险是团队容易误以为“合成就安全”。我会从 approved purpose 开始, 明确这个数据是用于 KYC OCR 测试、AML typology training、payment fraud simulation, 还是 contact center copilot QA。然后检查 source data permission, 因为合成数据不能自动摆脱原始数据的目的限制和合同边界。

架构上我会建立三轴评估: privacy、utility、fidelity。Privacy 覆盖 membership inference、model inversion、nearest-neighbor、linkage、canary 和 PII scan; utility 看它是否支撑批准任务; fidelity 看业务结构是否真实, 但不能过度复制真实个体。再加上 representativeness 和 bias amplification review, 避免信贷、投诉、KYC 和客服场景复制历史偏差。

最后每个数据集要有 data card 和 allowed-use license, 说明可用于什么、禁止什么、谁能访问、多久过期、是否可外发、派生数据如何处理。release gate 根据风险分层, 高风险训练、模型验证或供应商释放必须有 Privacy、Model Risk、Legal、Security 和 Business Owner 的 evidence-based sign-off。

CTO版本

我不会把 synthetic data 平台定位成单纯生成工具, 而会定位成 AI data product control plane。CTO 关心的是复用速度、平台一致性、审计压力和事故半径。我的建议是建设一个轻量但强约束的 lifecycle: catalog + generator registry + attack workbench + scorecard + license + provenance + retention。

这样工程团队可以通过标准接口申请和消费合成数据, 不需要每个项目重新发明脚本; 风险团队可以看到 source permission、attack evidence 和 residual risk; 平台可以用 watermark、metadata、access policy 和 expiry 防止合成数据在 notebook、RAG index、agent sandbox 和 vendor environment 中失控。商业价值不是“我们有更多假数据”, 而是“我们能更快测试高风险 AI 场景, 同时把隐私、偏见、用途漂移和审计不可追溯的风险前移控制”。

---

7-day practice plan

---

Source anchors with links