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 行写清楚，合规设计基本才算开始。