当基础库有安全风险时，你的产品该停就停
Fulcrum Therapeutics 裁员 85%，不是因为自己的药有问题——而是因为同一靶点上的另一款药（Tazverik）因癌症风险被撤市，FDA 据此判定新药风险不可接受。
如果你只把这当生物科技新闻，就白读了。
对 AI 产品开发者而言，这是一个教科书级的依赖风险传染案例。你的产品可能用到某个开源模型、API 或组件，只要那个组件被认定为不安全，你的产品就会被连坐——哪怕你从未触发过任何事故。
问题：用户真正需要的是“安全可用”，而不是“还没出事”
镰状细胞病患者需要口服药 pociredir，但 FDA 的立场很清楚：同类药物已经证明 PRC2 抑制有潜在致癌性，就算这个新药目前没出问题，风险轮廓也不可接受。
产品视角下，这叫预期风险大于预期收益。
开发者经常犯的错：只盯着功能跑通，忽略非功能风险的可传递性。你用了一个基于某大模型微调的翻译 API，那个模型后来被曝在训练数据中存在大量有害内容，监管部门要求下架所有基于该模型的衍生服务。你的产品哪怕一行问题回复都没输出过，也要跟着下架。
现有方案的设计分析：重检测、轻预防
大多数 AI 产品的风险管控是“事故驱动”的：
- 出安全事件 → 打补丁 → 复盘
- 没出事 = 安全
这种模式成本极高。Fulcrum 在 pociredir 进入临床后才因为 Tazverik 的撤市被叫停，前期数亿美金研发全部归零。
AI 产品的类似案例：Stability AI 的 Stable Diffusion 被诉侵权后，整个开源生态的合规审查成本激增，大量衍生项目被迫终止。预防远比事后补救便宜。
产品决策逻辑：建立“依赖风险图谱”
FDA 的决策逻辑是：如果同类药物的某个机制已被证明有严重风险，新药通过同一机制作用就自动触发“不可接受”。
这对应到 AI 产品决策：
- 识别关键依赖项：列出产品所有非自研的模型、数据、API、框架。
- 标注依赖项的风险状态：每个依赖是否处于“被监管审查/被指控侵权/被社区弃用”状态？
- 制定早期终止条件：当某个依赖的风险状态达到临界值，自动触发“停止开发或立即切换方案”。
具体可执行：每个迭代周期增加一项“依赖合规检查”，类似代码审查。
交互设计要点：让“停止”按钮比“继续”更易触发
产品经理常忽略“停止”体验的设计。
- 应该有一个明确的风险仪表盘，实时显示依赖项健康状况（绿色/黄色/红色）。
- 当依赖项变红，系统自动发出预警，要求产品负责人确认是否继续。
- 最好还有“后退机制”支持：假如依赖项出问题，能否快速切换替代方案？如果切换成本过高，就需要提前准备。
这一点类似软件工程中的“特性开关”，只不过用来控制风险暴露。
可执行的改进建议
- 两周一次依赖审计：用工具（如 Dependabot、Snyk）自动扫描依赖安全问题，但还要加上“商业风险扫描”：比如该依赖的母公司是否正在被调查、是否有未解决的诉讼。
- 建立风险容器：对高风险依赖，设计隔离层，使得依赖出问题时可以快速摘除而不影响核心功能。例如，将 NLP 模型封装为微服务，随时可更换模型实例。
- 产品设计文档中增加“默认关闭”条款：如果你的产品依赖某外部 API，默认该 API 可能随时不可用，需准备备选。不要在功能上线后才想替代方案。
最后
Fulcrum 的教训提醒我们：产品安全不只是你自己写的代码安全，更是你所用一切的安全。 FDA 今天叫停个药，明天就可能叫停一个 AI 应用（比如欧盟 AI Act 的“高风险分类”）。
开发者在设计架构时，把“依赖风险传染性”当做一等公民对待——这和性能、并发、可扩展性同样重要。
