核心摘要
AI 隐私工程本质上是数据血缘问题。一次用户请求可能变成 Prompt、输出、Trace、工具结果、Embedding、向量记录、缓存、滥用样本、评测用例、客服工单和训练样本，并跨越多个处理者。
隐私政策无法控制这张图。系统必须具备：
- 每项处理活动对应的目的和法律依据决策；
- 控制者、处理者与 Subprocessor 边界；
- 对象级血缘与保留规则；
- 遍历全部相关系统的权利履约工作流；
- 能说明搜索、修改、保留或适用例外情况的证据。
Embedding 和训练模型都不能自动视为匿名。GDPR 与 CCPA 也不是可互换的“同意制度”。应建设一套可表达各司法辖区决策、同时共享可审计数据清单的控制平面。
本文提供工程模式，不构成法律意见。产品涉及的适用范围、角色、法律依据、告知、合同条款、例外和响应时限，应由专业法律顾问确认。
核心要点
- 目的是隐私架构的主键。 “改进 AI”过于宽泛，无法约束收集、保留和复用。
- 血缘必须覆盖派生和复制数据。 删除源记录不会自动删除向量、缓存、Trace、导出和训练快照。
- 匿名性是需要证明的结果，不是可以随意贴的标签。 哈希标识符或转换成 Embedding 都不能自动证明匿名。
- 权利履约必须产出证据。 只有绿色流程状态、没有逐系统结果，无法支撑审计或用户解释。
- 供应商设置不能替代合同与架构。 No-training、Zero-retention、Region、Subprocessor 和跨境机制必须一致。
从处理矩阵开始，而不只是列数据类型
数据清单说明“有什么”，处理矩阵说明每项操作“为什么被允许，以及受到什么约束”。
| 活动 | 目的 | 数据 | 角色/边界 | 关键决策字段 |
|---|---|---|---|---|
| 生成回答 | 服务交付 | Prompt、文件、输出 | 控制者到模型处理者 | 必要性、保留、跨境 |
| 滥用检测 | 安全 | 元数据、选定内容 | 控制者/内部处理者 | 比例性、访问、复核 |
| 产品分析 | 分析 | 事件元数据 | 控制者/分析处理者 | 最小化、退出规则 |
| 质量评测 | 评测 | 精选交互样本 | 独立内部目的 | 来源、脱敏、保留 |
| 模型微调 | 训练 | 已批准数据集 | 控制者或联合边界 | 法律依据、权利、模型风险 |
| 客服排查 | 支持 | 工单、Trace、选定内容 | 受限员工/供应商 | 个案范围、时限 |
每一行都应记录：
purpose_id
purpose_owner
data_categories
data_subjects
special_or_sensitive_categories
controller_processor_role
legal_basis_or_CCPA_business_purpose
necessity_assessment
notice_version
retention_rule
rights_supported
recipients_and_subprocessors
transfer_mechanism
security_controls
DPIA_or_risk_assessment_reference
不能为整个产品指定一个法律依据。为了回答用户而使用 Prompt，与把该 Prompt 复用于分析、评测或训练，是不同目的，必须分别判断。
GDPR 与 CCPA：不同法律模型，共享工程原语
GDPR 工程问题
CNIL 的 AI 建议强调：AI 系统开发应明确目的，判断控制者/处理者角色，选择法律依据，最小化数据，确定保留期，并保障数据主体权利。EDPB Opinion 28/2024 进一步讨论了 AI 模型匿名性、合法利益，以及违法处理个人数据可能产生的后果。
工程系统应呈现以下问题，不能擅自替法律团队作结论：
- 目的是否具体并已告知？
- 每个数据字段对该目的是否必要？
- 哪个实体决定处理目的与手段？
- 处理者是否为自身目的复用数据？
- 是否预期或推断特殊类别数据？
- 在适用情况下，个人能否反对、撤回同意，或行使访问、删除和更正？
- 自动化决策是否产生法律或类似重大影响？
- 下游副本能否执行限制或删除？
CCPA/CPRA 工程问题
加州总检察长的 CCPA 官方说明列出的权利包括：
- 知情；
- 删除，但存在例外；
- 更正不准确个人信息；
- 退出出售或共享；
- 限制敏感个人信息的特定使用和披露；
- 行使权利不受歧视。
CPRA 是对 CCPA 的修订，不是另一部替代法律。适用范围、定义、例外、身份验证和必要告知都需要法律分析。
工程影响十分具体：Opt-out 信号必须传播到已由正式策略判定为出售或共享的每条路径。CalPrivacy 的执法案例也表明，在退出流程中制造不必要摩擦会形成监管风险。不能仅因为另一类权利请求需要身份验证，就对所有 Opt-out 强制相同验证；应执行该请求类型获批的验证规则。
建立 AI 数据血缘图
有效血缘图应沿对象身份和派生关系展开：
每个节点都应暴露：
- 稳定对象 ID；
- 仍被维护的主体或租户关联；
- 来源 ID 与派生类型；
- 目的与策略版本；
- 物理存储和区域；
- 处理者与 Subprocessor；
- 创建和过期时间；
- Legal Hold 或例外状态；
- 删除、更正与限制能力；
- 下游对象 ID。
为什么 User ID 不够
数据副本经常丢失原始 user_id：
- 向量只保留 Chunk 元数据；
- Trace 使用 Request ID；
- 导出使用 Dataset Sample ID；
- 供应商返回自己的请求 ID；
- 模型快照只引用 Dataset Version。
因此需要隐私关联服务或血缘索引来解析这些标识，同时避免把原始个人数据复制到每个系统。
Embedding 与模型不能自动视为匿名
三种常见捷径都不可靠：
- “已经删除姓名。” 准标识符和内容仍可能定位个人。
- “它已经变成 Embedding。” 数据转换不会自动消除可关联性、成员推断风险或敏感语义。
- “信息已经进入模型权重。” EDPB 指出，模型匿名性必须个案评估：使用合理可能采用的手段，能否提取或通过查询获得个人数据。
评估至少应记录：
对于能够重新连接身份的一方，假名化数据仍属于个人数据。应把假名化视为控制措施，而不是自动退出适用范围。
不必收集一切的日志与观测
默认遥测通常可以避开原始内容：
| 观测需求 | 更低内容暴露的信号 |
|---|---|
| 延迟 | 路由、模型快照、时间戳 |
| 成本 | Usage Counter 与费率版本 |
| 稳定性 | 类型化错误和重试次数 |
| 检索质量 | 文档 ID 和排名，不存全文 |
| 安全 | 分类器类别和策略版本 |
| 调试 | Request ID 与短期、审批后采样 |
如果确实需要采集内容：
- 只针对窄范围目的和时间窗口开启；
- 在适用时提供可见或合同告知；
- 可行时在持久化前脱敏；
- 使用字段级权限和可审计 Break-glass；
- 阻止自动流入分析或训练；
- 到期后关闭采集并验证删除。
正则脱敏无法理解上下文、自由格式密钥、图片或多字段重识别组合。
把权利履约做成证据生产工作流
请求阶段
received
-> 司法辖区与请求类型分类
-> 选择身份/授权验证规则
-> 判断范围与例外
-> 规划血缘搜索
-> 执行各系统与处理者动作
-> 对账失败
-> 审批答复和证据包
-> 完成或进入申诉
工作流必须支持部分结果。某些数据可能删除，某些更正，某些因成文例外保留，某些则在争议审查期间受到限制。
Go 示例：带证据的删除扇出
示例要求每个存储返回结构化证据。生产实现还应持久化工作流状态、安全重试、加密证据包，并避免在日志中记录个人内容。
package main
import (
"context"
"errors"
"fmt"
"time"
)
type DeleteResult struct {
Store string
ObjectIDs []string
Action string
Exception string
CompletedAt time.Time
}
type Store interface {
Name() string
DeleteBySubject(ctx context.Context, subjectRef string) (DeleteResult, error)
}
type DeletionWorkflow struct {
PolicyVersion string
Stores []Store
}
type Evidence struct {
RequestID string
PolicyVersion string
Results []DeleteResult
Failures map[string]string
}
func (w DeletionWorkflow) Run(ctx context.Context, requestID, subjectRef string) (Evidence, error) {
if requestID == "" || subjectRef == "" {
return Evidence{}, errors.New("request and subject references are required")
}
evidence := Evidence{
RequestID: requestID, PolicyVersion: w.PolicyVersion,
Failures: make(map[string]string),
}
for _, store := range w.Stores {
result, err := store.DeleteBySubject(ctx, subjectRef)
if err != nil {
evidence.Failures[store.Name()] = err.Error()
continue
}
evidence.Results = append(evidence.Results, result)
}
if len(evidence.Failures) > 0 {
return evidence, fmt.Errorf("%d stores require retry or review", len(evidence.Failures))
}
return evidence, nil
}
func main() {
workflow := DeletionWorkflow{PolicyVersion: "privacy-2026-10"}
evidence, err := workflow.Run(context.Background(), "dsar-42", "subject-token-7")
fmt.Println(evidence.PolicyVersion, err)
}
空的 Stores 不能代表生产删除成功；Inventory 校验应拒绝缺少预期存储的工作流。
删除、更正与模型产物
删除传播
每个源对象都应定义以下位置的行为：
| 位置 | 可能动作 |
|---|---|
| 主记录 | 删除、限制或按例外保留 |
| 对象存储 | 删除原对象和派生物 |
| 向量索引 | 删除 Chunk 并重建受影响索引状态 |
| 缓存 | 清理 Key 和失效副本 |
| Trace/日志 | 按批准规则删除、脱敏或隔离 |
| 分析系统 | 删除个人级事件或采用批准的聚合处理 |
| 评测数据集 | 移除样本并发布新数据集版本 |
| 待执行训练任务 | 执行前阻止或重建 |
| 备份 | 按成文周期到期，并阻止普通恢复 |
| 外部处理者 | 发送请求并保留完成证据 |
从训练数据中删除样本，并不会在数学上移除它对既有模型的影响。是否需要重训、Unlearning、输出控制、限制或其他响应，取决于法律和技术评估。必须维护 Dataset 到 Model 的血缘，才能作出该决策。
更正传播
不能静默覆盖不可变证据。应把旧值标为已取代，在权威存储中应用更正，必要时重建派生产物，并阻止缓存或旧数据集快照把过时值重新写回系统。
控制者、处理者与 Subprocessor 边界
针对每个外部模型、向量数据库、可观测平台、客服工具和评测供应商，记录：
- 服务与法律实体；
- 各处理目的下的角色；
- 接收的数据类别；
- 是否用于训练或产品改进；
- 保留与删除能力；
- 存储和处理位置；
- Subprocessor 及变更通知；
- 国际传输机制；
- 安全与事件条款；
- 权利请求协助能力；
- 配置证据与合同版本。
“不训练”开关只处理一个目的。它不能证明 Zero Retention、无人审查、区域内处理、支持删除，也不能证明不存在 Subprocessor。
发布门禁
新 AI 功能
- 每个处理目的的矩阵都已批准。
- 数据流与血缘图和实现一致。
- 原始内容日志默认策略已评审。
- 供应商角色、保留、训练、区域和 Subprocessor 已记录。
- 权利工作流覆盖主存储与派生存储。
- 删除和更正测试覆盖缓存、向量、导出与处理者失败。
- 保留任务能够产出可验证证据。
- 访问控制和 Break-glass 使用可审计。
- 隐私告知与产品内控制符合实际行为。
- 风险评估有负责人和复审触发器。
新评测或训练数据集
- 每个样本都有来源与目的。
- 服务交付数据默认不复用。
- 法律依据与告知分析已记录。
- 敏感和特殊类别处理明确。
- 去重和脱敏不能替代权利支持。
- 数据集快照不可变，并关联模型/评测版本。
- 删除能够生成新数据集版本。
- 能识别受影响的下游模型。
常见失败模式
| 说法或设计 | 为什么失败 | 更好的控制 |
|---|---|---|
| “不训练，所以隐私已解决” | 日志、供应商、Trace 和权利仍存在 | 治理每个处理目的 |
| 一个同意覆盖全部 AI 用途 | 目的和法律依据不同 | 分开服务、安全、分析、评测、训练 |
| Embedding 已匿名 | 转换可能保留可关联性 | 保留血缘并评估风险 |
| 删除账户等于删除全部数据 | 派生和外部副本仍存在 | 按图执行删除 |
| 请求入队后即把 DSAR 标为完成 | 处理者可能失败或超时 | 要求逐系统完成证据 |
| 供应商 Region 等于数据驻留 | 支持、日志和 Subprocessor 可能不同 | 记录完整处理边界 |
| 备份删除等于立即覆盖 | 不可变备份可能延迟过期 | 隔离、定期到期、阻止普通恢复 |
常见问题
Prompt 是否必须保存？
不必须。很多稳定性和成本信号都能在不保存原文的情况下记录。只有针对明确目的，并具备最小化、访问、保留和权利处理时才保存内容。
同意是否总是最安全的法律依据？
不是。同意必须满足法律要求且可撤回；如果处理并非真正可选，同意可能不合适。应由法律顾问按目的选择依据。
删除向量是否会删除源文件？
不会。源文件、Chunk、Embedding、索引副本、缓存和导出是不同对象。必须关联它们，并定义删除顺序与验证。
删除训练数据集后，能否宣布模型匿名？
不能。删除数据集不等于证明模型匿名。应执行 EDPB 所述的个案评估，并测试提取和可识别风险。
权利请求需要多少身份验证？
应执行该请求类型和风险对应的获批规则。过度验证会收集更多数据并阻碍权利，验证不足则可能向错误的人披露信息。
一手资料
- CNIL，AI system development: recommendations to comply with the GDPR：AI 开发中的目的、角色、法律依据、最小化与权利建议。
- European Data Protection Board，Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models：模型匿名性、合法利益与违法处理问题。
- EDPB，Opinion 28/2024 官方新闻摘要：关于模型匿名性需个案评估的简明边界。
- California Attorney General，California Consumer Privacy Act：CCPA 权利与企业责任的官方说明。
- State of California，Rights under the California Consumer Privacy Act：知情、删除、更正、退出、限制和平等对待权利概览。
关联学习路径
- AI Agent 长期记忆与 GDPR：记忆特有的访问、保留与删除风险。
- EU AI Act 技术合规：数据保护之外的 AI 治理控制。
- 生成式 AI：生成数据与派生数据背后的系统类别。
- RAG：必须保留血缘的向量与证据流水线。
总结
删除姓名、关闭训练或发布隐私政策，都不足以实现 AI 隐私安全。系统需要约束每个目的的处理矩阵、覆盖派生与外部数据的血缘图，以及能够返回证据而不是乐观状态的权利履约工作流。
这些控制应在生产数据扩散到向量、Trace、评测集和模型版本之前完成。等删除请求或监管调查到来后再补血缘，成本更高、可靠性更低，也更难证明。