AI Ethics & Compliance：安全与合规
AI Ethics & Compliance：安全与合规
AI product 的合规问题，最大风险不是“忘了写免责声明”，而是团队默认觉得这些事可以后面再补。现实里，很多 AI feature 一旦先上线再补 safety，代价会非常高，因为风险不是只出现在 output，而是从 data collection、prompt design、tool access 到 user expectation 全链路都在扩散。
所以这页不讲法律条文背诵，而是从 PM 视角讲一套更实用的 AI safety 和 compliance thinking。
先说结论：AI 合规不是一个 review step，而是一条 design constraint
更实际的看法是：
- 不是上线前才审一次
- 不是法务一个 team 的事
- 不是只管敏感行业
任何生成式 AI product，只要涉及 user input、knowledge output、automation 或内容分发，就已经有合规和 safety 风险。
PM 最需要先识别的 4 类风险
| 风险 | 常见表现 |
|---|---|
| accuracy risk | 一本正经答错，用户还信了 |
| privacy risk | 把不该进模型的数据送进去了 |
| misuse risk | 用户拿产品做不该做的事 |
| IP / copyright risk | 生成结果或训练材料有版权问题 |
这 4 类风险里，最危险的不是“概率最高”的那个，而是“发生一次就很贵”的那个。
风险不是统一处理，要按 use case 分级
一个很实用的分类法：
| use case | 风险等级 | 为什么 |
|---|---|---|
| brainstorming | 低 | 出错影响有限 |
| draft generation | 中 | 用户可能直接拿去外发 |
| support answer | 中到高 | 错答会影响 trust 和运营成本 |
| hiring / finance / legal / medical | 高 | 一次错误就可能造成严重后果 |
风险分级做不清，后面所有 guardrail 都会太松或太重。
Guardrail 应该前中后都做
更完整的 guardrail 不是只过滤 output，而是 3 层：
| 层 | 主要问题 | 典型做法 |
|---|---|---|
| input guardrail | 用户输入能不能直接进系统 | 长度限制、敏感内容检测、prompt injection 防护 |
| processing guardrail | 模型怎么被约束 | system prompt、tool permission、retrieval boundary |
| output guardrail | 最终结果能不能直接给用户 | policy check、source display、human review、fallback |
只做 output moderation，通常不够。
Privacy 问题，往往不是“泄露”，而是“默认收太多”
PM 在设计 AI feature 时，很容易把“多给一点上下文，模型效果更好”当成默认策略。
但这常常会直接把数据边界做坏。
更稳的原则还是 data minimization：
| 场景 | 真正需要的数据 | 经常被多拿的数据 |
|---|---|---|
| AI summary | 文本内容本身 | 用户全量 profile |
| AI support | 问题上下文、订单必要字段 | 整份 CRM 历史 |
| AI writing | 写作目标和 style | 不相关浏览轨迹 |
如果一个字段不是这次任务必需，就先别送进去。
Prompt Injection 和 Tool Abuse 不是只有工程师要管
PM 也需要知道产品层面会发生什么。
典型问题包括：
- 用户诱导模型忽略原有规则
- 通过 tool calling 越权访问数据
- 借你的 product 生成违规内容
这意味着在设计 tool-enabled AI feature 时，你不只是在设计“能做什么”，也在设计“绝对不能做什么”。
Source Grounding 是 trust 的关键
在中高风险场景下，光让模型“回答得像对的”完全不够。
更稳的方向是：
- 能引用 source 就引用
- 不确定就明确说不确定
- 超出边界就拒答或转人工
这类机制会牺牲一点“丝滑感”，但通常能换来更长期的 trust。
Compliance Review 应该问什么
上线前，PM 至少应该能回答：
- 这个功能最坏会错到什么程度
- 哪类数据进入了模型
- 用户是否知道 AI 在参与
- 是否需要提供 source、disclaimer 或人工升级路径
- 出现 bad output 后怎么处置和追踪
如果这 5 个问题都还模糊，说明合规设计还没完成。
最容易出事的 4 种心态
| 心态 | 为什么危险 |
|---|---|
| 先上线，再补 guardrail | 风险会先到用户身上 |
| 模型厂商会帮我们兜底 | 责任不会自动转移出去 |
| 只是内部工具，不需要管太严 | 内部也可能处理敏感数据 |
| 低频风险先不看 | AI 风险 often low-frequency but high-impact |
AI PM 最该避免的，就是把安全问题当成“以后再说”的 technical debt。
一套够用的 PM Checklist
- 这个 use case 属于低、中还是高风险
- 输入里有没有不必要的敏感数据
- output 错了会带来什么真实后果
- 有没有 source / disclaimer / escalation path
- 有没有 bad case logging 和 rollback 机制
这套 checklist 不复杂，但很实用。很多事故，提前过一遍就能挡掉。
Practice
拿你正在做的一个 AI feature，写下这 4 行：
- 最坏情况下它会怎么伤害用户或业务
- 哪些数据其实不该被送进模型
- 哪些问题模型应该拒答
- 错误输出后谁来发现、谁来处理
你把这 4 行写清楚，合规设计基本才算开始。
📚 相关资源
❓ 常见问题
关于本章主题最常被搜索的问题，点击展开答案
AI 合规为什么不能等到上线前才审一次？
合规不是 review step，是 design constraint。风险不只在 output——data collection、prompt design、tool access、user expectation 全链路都在扩散。先上线再补 safety 代价非常高，因为问题会先到用户身上、责任也不会自动转移给模型厂商。
AI PM 要识别的 4 类风险是什么？
(1) accuracy risk（一本正经答错，用户还信了）(2) privacy risk（不该进模型的数据送进去）(3) misuse risk（用户拿产品做不该做的事）(4) IP / copyright risk（生成或训练材料有版权问题）。最危险的不是「概率最高」的，而是「发生一次就很贵」的那个。
AI guardrail 应该做几层？
3 层：input guardrail（长度限制、敏感内容检测、prompt injection 防护）、processing guardrail（system prompt、tool permission、retrieval boundary）、output guardrail（policy check、source display、human review、fallback）。只做 output moderation 通常不够。
AI 产品的隐私问题为什么常常不是「泄露」而是「默认收太多」？
PM 容易把「多给一点上下文模型效果更好」当默认策略，这会直接把数据边界做坏。原则是 data minimization：AI summary 只送文本本身而不是用户全量 profile；AI support 只送问题上下文与必要订单字段而不是整份 CRM 历史；AI writing 只送写作目标与 style 而不是浏览轨迹。字段不是这次任务必需就别送。
上线前 PM 必须回答的 compliance 5 问是什么？
(1) 这个功能最坏会错到什么程度 (2) 哪类数据进入了模型 (3) 用户是否知道 AI 在参与 (4) 是否需要 source、disclaimer 或人工升级路径 (5) 出现 bad output 后怎么处置和追踪。这 5 个还模糊，说明合规设计还没完成——别把安全当成「以后再说」的 technical debt。