Data Governance & Privacy
AI Data Governance 与 Privacy
企业做 LLM feature，最容易被忽略的不是 model 效果，而是 data flow。
很多 demo 能跑，是因为它默认“什么都能传给 model”；很多 project 上线困难，也是因为到了 compliance review 阶段才发现没人说得清 data 从哪来、到哪去、留多久。
这章要解决什么问题
你需要能回答下面这些问题：
- 这次 model 调用到底带了哪些 data？
- 哪些数据必须脱敏，哪些数据根本不该上传？
- 临时 file、chat 记录、retrieval 片段会保留多久？
- 不同 region、不同客户的 data 能不能混放？
- 出了问题，能不能追溯是谁 access 过什么？
如果这些问题没有明确答案，product 再聪明，也很难进入 enterprise 场景。
三条底线原则
1. 最小必要
给 model 的内容只包含完成 task 必须的 data。
例如做 meeting notes summary，通常不需要把整条 CRM record、用户身份证号、支付信息一起带上。
2. 用途限定
data 只用于当前声明的 task。
今天为了总结 document 而 upload 的 data，不应自动拿去做 training sample 或长期 memory。
3. 环境隔离
dev、test、production 环境的 secret、log、storage 都要分开。
不要把 production 对话拷进本地 prompt playground 做 debug。
一条完整的 data handling pipeline
| Stage | 该做什么 | 常见错误 |
|---|---|---|
| Ingress | 校验 file 类型、大小、来源 | 什么都收，后面再说 |
| Preprocess | 脱敏、classification、chunking | 原文直接发给 model |
| Retrieval | 按 tenant、permission 取 data | retrieval scope 过大 |
| Generation | 只给当前 task 必需 context | 把 history 全塞进去 |
| Egress | output 脱敏、内容审查 | 把原始片段直接返回用户 |
| Storage | 定义 TTL、加密、audit | 永久保存临时 file |
Data classification 要可执行，不要只写在 PPT 里
一个够用的分类方式：
| Data level | 例子 | 处理建议 |
|---|---|---|
| Public | 官网文案、公开 FAQ | 可直接用于 retrieval |
| Internal | 内部 SOP、培训资料 | 控制 access scope，保留 audit |
| Confidential | 合同、报价、业务报表 | 严格 permission control，限制外发 |
| Sensitive / PII | 手机号、邮箱、证件号、住址 | 默认脱敏，不直接进 model |
| Secret | API key、database password、私钥 | 禁止进入 prompt 与 log |
注意，classification 不是为了“看起来专业”，而是为了决定每一类 data 能不能被 upload、cache、记录和展示。
脱敏与 Preprocess
常见要处理的字段包括：
- 手机号、邮箱、地址
- 用户 ID、订单号、账户号
- 银行信息、身份证件
- 企业内部项目代号、客户名单
建议把脱敏做成独立的 preprocess step，而不是分散在 business logic 里。
这样你才能统一升级 rule，也更容易做 tenant-level 配置。
Storage 与 Retention 策略
哪些内容不应该长期 retention
- 临时 upload 的音视频 transcript
- 中间 reasoning 草稿
- debug 阶段的 prompt / response
- 带敏感 context 的 failure log
哪些内容可以保留，但要加限制
- 结构化 task result
- 已脱敏的 audit log
- model 调用 metadata
- 用户授权保存的 conversation summary
可以直接采用这样的 retention policy：
| Data 类型 | 建议 TTL |
|---|---|
| 临时 file | 24 小时到 7 天 |
| 中间解析结果 | 1 到 3 天 |
| audit log | 按 compliance 要求保留 |
| business result | 由业务 system 管理，不跟 model cache 混放 |
Region 与 Tenant 隔离
enterprise project 里，一个常见坑是“逻辑上分 tenant，物理上混在一起”。
更稳的做法是至少做到：
- retrieval 和 database access 统一带
tenant_id - vector store 或 index 按 tenant 做逻辑隔离
- 不同 region 走不同 storage 与 provider routing
- 某些客户可关闭 training、log retention 或外部 model 调用
如果 system 服务多个国家或 enterprise 客户，这一层最好在 architecture design 时就决定，不要等签单后再补。
第三方 Model 与 Tool 接入
接 provider 时，重点不只是 API 能不能调通，还要 confirm：
- 是否支持关闭 data training
- 默认 log retention 多久
- 是否签了 DPA 或企业协议
- data 是否跨区处理
- tool calling 和 log 里会不会泄露原始内容
self-hosted model 也不是天然安全。你还要自己负责：
- image 与 dependency update
- network egress control
- storage encryption
- audit 与 patch cadence
Audit 与 Access Control
至少要留下这些信息：
- 谁 access 了什么 data
- 什么时候发起调用
- 使用了哪个 model 和哪个版本配置
- 是否命中过脱敏或 security policy
- 是否调用了 high-risk tool
但要注意，audit log 本身也可能成为敏感 data source。
所以 log 要“可追踪”，不等于“全部 raw content 照存”。
Minimum launch checklist
- data 先 classification，再决定能否进 model
- sensitive field 在入模前脱敏
- 临时 data 设置 TTL
- retrieval 和 tool access 做 tenant 隔离
- audit log 记录 action，不盲目保存 raw content
- 明确 provider 的 retention 和 training policy
动手练习
拿你的一条 AI workflow 做一次盘点：
- 画出从用户 input 到 model output 的全链路
- 标出哪里会接触 PII
- 标出哪些 data 其实没必要 upload
- 给每一类 data 写一个 retention 时长
做完这一步，你的“data governance”才算真正落到 system 里。