AI Synthetic Data Governance Privacy-Utility-Fidelity Playbook

配对阅读：本手册的原理/架构解读版是 docs/ai-foundations/papers/173-ai-synthetic-data-governance-privacy-utility-fidelity-architecture.md。先读 paper 建立机制与取舍，再用本手册落地为模板、RACI 与门禁，两者不需要重复精读。

版本: v1.0
日期: 2026-06-30
范围: 金融零售 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.
• Product, process and architecture owners 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:

---

Design Review Questions

Product questions

Process and rule 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.

---

Domain Failure Analyses

Vendor release is not automatically safe

Synthetic data is not automatically safe for vendor use. The release path depends on source permission, contract terms for derivative data, privacy attack evidence and the allowed-use license. External or partner release belongs in G4 unless governance explicitly narrows the audience, environment, retention, operations and deletion obligations.

The core 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. Higher fidelity for vendor testing is a risk trade-off requiring stronger controls, not an informal data share.

Privacy, utility and fidelity are separate gates

Privacy, utility and fidelity should not be averaged into one score.

Payment fraud simulation illustrates the trade-off: transaction timing, device changes and merchant patterns need realism, but exact rare fraud sequences can expose source cases. A safe design abstracts typologies, generates plausible variants, suppresses unique combinations, runs linkage and nearest-neighbor tests, and measures rule trigger coverage plus investigator realism.

Credit model augmentation is high impact

Synthetic credit data can alter model boundaries, subgroup behavior and adverse action explanations. It is suitable for sensitivity analysis, challenger testing, rejected-inference exploration or scenario stress testing only when source permission, model-risk approval, privacy attack evidence, policy-valid features, subgroup coverage, reason-code stability and usage limits are explicit.

Production training input requires a higher gate. The scorecard should include distribution fidelity, business rule validity, subgroup performance, proxy-feature review, label provenance, adverse action reason stability and membership/linkage testing. The license should prohibit production scoring and unrelated use unless explicitly approved.

Contact center transcript generation needs minimization

Raw transcripts should not be sent to uncontrolled generators. Contact center data may contain authentication phrases, account details, hardship signals, health or vulnerability disclosures and employee behavior. A safer design uses approved intent labels, redacted summaries and policy constraints in a controlled environment.

Utility should be measured through intent classification, escalation coverage, copilot QA and SME realism. Bias review should check that generated language does not stereotype customers with low digital confidence, accents, vulnerability markers or complaint intensity. The license should prohibit employee performance analytics, unrelated sentiment profiling and reconstruction attempts.

Audit evidence must be replayable

The evidence packet should allow internal audit to replay why a dataset was created, why it was safe enough for the approved use, who approved it and how misuse is controlled.

Minimum evidence:

• intake and business purpose;
• source permission matrix and data classification;
• generation plan, generator version, prompts/rules and environment evidence;
• privacy attack report;
• utility/fidelity scorecard;
• bias/coverage review;
• data card and allowed-use license;
• watermark/provenance evidence;
• approval record and residual risk owner;
• retention plan, deletion proof where applicable and access logs.

External sharing adds contract terms, vendor access logs and deletion evidence. Model-impacting use adds model-risk sign-off and monitoring thresholds.

---

Source anchors