AI Synthetic Data Governance Privacy-Utility-Fidelity Playbook

版本: v1.0
日期: 2026-06-30
适用对象: AI 产品经理、CBAP / Senior BA、数据产品架构师、AI 架构师、隐私风险伙伴、模型风险管理、金融零售业务负责人、数据治理、信息安全、内审

---

Purpose and when to use

本手册用于把 synthetic data 从“项目临时生成文件”升级为可治理、可发布、可审计的数据产品。它适合以下场景:

使用边界:

• 本手册不是法律意见、隐私影响评估结论、模型验证报告或监管解释。
• Synthetic data 不自动等于 anonymized / de-identified / safe for sharing。
• 如果 source data 不允许某用途, 不能靠“合成”绕过目的限制、合同边界或客户期望。
• 高风险 synthetic data 只有在 privacy、utility、fidelity、bias、license 和 release evidence 都满足门槛后, 才能释放。

---

Operating model

1. Lifecycle

Intake
-> source permission review
-> generation design
-> controlled build
-> privacy attack testing
-> utility/fidelity scoring
-> bias/coverage review
-> data card and allowed-use license
-> release gate
-> catalog, access, monitoring
-> renewal, restriction or retirement

2. RACI

RACI discipline:

• Business Owner owns why the synthetic data is needed and accepts business residual risk.
• Data Owner owns source permission and release scope.
• Privacy and Security own leakage, re-identification, environment and access controls.
• Model Risk owns model-impacting uses, especially credit, fraud, AML and decision-support augmentation.
• PM / BA / Architect ensure the license is embedded in PRD, architecture review, release checklist and vendor handoff.

3. Gate levels

---

Template: synthetic data intake

Intake decision rule:

No approved use, no source permission, no release.

---

Template: source permission matrix

Permission checks:

• Does the original collection purpose support synthetic generation for this use?
• Does any contract or policy restrict derivatives, vendor sharing, retention or model training?
• Are there fields that must be excluded before generation rather than redacted after generation?
• Does source data include rare events whose structure could identify a customer even after field removal?
• Will intermediate artifacts be deleted or retained as evidence?

---

Template: privacy attack checklist

Privacy result classification:

---

Template: utility/fidelity scorecard

Decision rule:

Utility must be measured against the approved use, not against generic realism.
Fidelity must preserve business structure without copying customer-identifying facts.

---

Template: bias/coverage review

Bias decision categories:

---

Template: allowed-use license

Dataset ID: SYN-PAY-FRAUD-SEQUENCE-2026-002
Version: v1.0
Status: Limited release
Approved purpose: Payment fraud rule and warning UX stress testing.
Allowed users: Fraud Risk Analytics, Payment Platform QA, named AI copilot test engineers.
Allowed environments: Enterprise non-production fraud sandbox only.
Allowed operations: Query, aggregate, run fraud rule simulations, run agent workflow tests, create test reports.
Prohibited operations: Production decisioning, customer scoring, external sharing, model pretraining, customer re-identification, linkage to production customer tables, employee performance analytics.
Derivative rule: All derivative samples, embeddings, reports and test fixtures inherit this license and must retain synthetic marker.
Watermark/provenance: Dataset metadata must retain synthetic=true, source_permission_id, generation_run_id and license_id.
Retention: Delete working copies after 90 days. Evidence packet retained under governance retention schedule.
Review trigger: New fraud typology source, vendor release request, model training request, privacy attack finding, incident, expiry.
Approvers: Business Owner, Data Owner, Privacy, Security, Model Risk, Architect.

License table version:

---

Template: release evidence packet

Release decision log:

---

PM/BA/architecture questions

Product questions

BA questions

Architecture questions

Privacy/risk questions

---

Release checklist

Use this checklist before any G2+ release.

Hard-stop conditions:

• Source permission is unclear or denied.
• Direct identifiers or near-copies remain.
• Membership inference, linkage or inversion risk exceeds threshold.
• Utility evidence does not support requested use.
• Bias review identifies unacceptable customer or conduct risk.
• Downstream use includes production decisioning without explicit high-risk approval.
• Vendor release lacks contract, retention and deletion evidence.

---

Executive narrative

1-minute version

Synthetic data can accelerate AI delivery, but only if it is governed as a data product. The main risk is not that the data is fake; the risk is that teams treat it as automatically safe, then use it for training, testing, vendor sharing or analytics beyond its permission boundary. Our architecture introduces risk-tiered release gates: source permission, generation controls, privacy attack testing, utility/fidelity scoring, bias review, data card, allowed-use license, provenance and retention. This lets us use synthetic AML, KYC, credit, fraud, contact center and complaint datasets safely enough for approved purposes while preserving audit evidence.

CTO / CDO version

The platform decision is to build a synthetic data control plane, not a loose generation toolkit. The control plane standardizes intake, generator registry, source permission, privacy attack workbench, scorecards, catalog, license enforcement, watermark/provenance and expiry. Engineering gets reusable datasets and faster test coverage. Data governance gets a record of what was generated, from which source, for which use, and under which restrictions. Risk teams get evidence that privacy, utility, fidelity and bias were measured before release. This reduces duplicated scripts, vendor sandbox sprawl and hidden training-data contamination.

CRO / Privacy version

Synthetic data does not remove privacy or conduct risk by definition. The release gate must prove that the dataset cannot reasonably expose real customers, rare cases, documents, calls or transaction paths, and that it will not be used outside the approved purpose. The evidence package includes source permission, membership inference and linkage testing, model inversion review where relevant, bias/coverage review, residual risk owner, retention and deletion plan. For high-risk uses, approval is conditional and time-bound.

---

Interview drills

Drill 1: “Is synthetic data automatically safe to use with vendors?”

30 秒答案:

Synthetic data is not automatically safe. I would first check source permission, whether the vendor contract allows derivative data, and whether the dataset passed privacy attack testing. For vendor release I would require a G4 gate: data card, allowed-use license, watermark/provenance, access restrictions, retention period, deletion proof and explicit prohibition on model training or onward sharing unless approved.

2 分钟展开:

The key mistake is assuming that removing direct identifiers or generating records from a model eliminates privacy risk. Synthetic data can preserve rare transaction patterns, complaint narratives, KYC document artifacts or fraud graph structures that support linkage or membership inference. For vendor use, I would narrow the purpose, reduce fidelity where needed, test for nearest-neighbor similarity and PII leakage, confirm contractual restrictions, and require evidence that the vendor cannot reuse the data for unrelated model training. If the vendor needs higher fidelity, that is a risk trade-off requiring stronger controls, not an informal data share.

Drill 2: “How do you balance privacy, utility and fidelity?”

30 秒答案:

I treat privacy, utility and fidelity as separate gate dimensions, not one averaged score. Privacy asks whether real people or cases can be inferred. Utility asks whether the dataset supports the approved task. Fidelity asks whether it preserves the relevant business structure without copying protected facts. Any hard failure can block or narrow release.

2 分钟展开:

For example, payment fraud simulation needs realistic transaction timing, device changes and merchant patterns, but copying exact rare fraud sequences can expose source cases. I would abstract typologies, generate plausible variants, suppress unique combinations, and run linkage and nearest-neighbor tests. Then I would measure utility through rule trigger coverage and investigator realism scores, and fidelity through sequence validity. If privacy is strong but utility is weak, the dataset may be suitable for demos but not rule validation. If utility is strong but privacy fails, it cannot be released until regenerated or restricted.

Drill 3: “What makes a synthetic dataset fit for credit model augmentation?”

30 秒答案:

It needs source permission, model-risk approval, privacy attack evidence, policy-valid features, subgroup coverage, reason-code stability and clear limits. I would not let synthetic credit data become production training input unless Model Risk, Privacy, Data Owner and Business Owner approve the use and evidence shows it does not amplify bias or distort adverse action explanations.

2 分钟展开:

Credit is high impact because synthetic data can alter model boundaries and fairness behavior. I would define whether the dataset is for sensitivity analysis, challenger testing, rejected-inference exploration or actual training. The scorecard would include distribution fidelity, business rule validity, subgroup performance, proxy-feature review, label provenance, adverse action reason stability and membership/linkage testing. The license would prohibit production scoring and unrelated use unless explicitly approved. This protects the organization from treating synthetic scenarios as ground truth.

Drill 4: “How would you govern contact center transcript generation?”

30 秒答案:

I would avoid sending raw transcripts to an uncontrolled LLM. I would use approved intent labels, redacted summaries and policy constraints to generate synthetic conversations, then run PII scans, phrase similarity checks, vulnerability-language review and utility testing against copilot QA or intent classification tasks. The data card must say it is synthetic and cannot be used as real customer evidence.

2 分钟展开:

Contact center transcripts contain authentication phrases, account details, hardship signals, health or vulnerability disclosures and employee behavior. The generator should operate in a controlled environment using minimized source features. Utility should be measured by intent classification accuracy, escalation coverage and SME realism. Bias review should check that the synthetic language does not stereotype customers with low digital confidence, accents, vulnerability markers or complaint intensity. The license should prohibit employee performance analytics, sentiment profiling beyond approved QA, and any attempt to reconstruct real calls.

Drill 5: “What evidence would you show internal audit?”

30 秒答案:

I would show the intake, source permission matrix, data classification, generation plan, privacy attack report, utility/fidelity scorecard, bias review, data card, allowed-use license, watermark/provenance evidence, approval record, residual risk owner, retention plan and access logs. The goal is to replay why the dataset was created, why it was safe enough for that use, who approved it and how misuse is controlled.

2 分钟展开:

Audit does not need a story that “synthetic means safe”; it needs evidence. I would connect the dataset ID to PRD, ADR, release gate and downstream systems. The evidence packet should show source owners approved the purpose, privacy tests were run, utility was measured against the actual task, limitations were disclosed, and access was limited to approved environments. If the dataset was shared externally, I would add contract terms, deletion proof and vendor access logs. If it was used for model training or validation, I would include model-risk sign-off and monitoring thresholds.

---

Source anchors