AI产品安全底线

针对涉及用户情绪、心理健康等敏感场景的 AI 产品,将安全要求拆分为”架构层”和”运营层”两张独立打分清单的安全设计范式。

简介

AI 产品安全底线是一套为涉及用户情绪安全的 AI 产品(如心理健康、情绪陪伴、自杀风险干预等)设计的安全评估框架。其核心理念是把安全要求拆成两个独立层面来评估:架构层(代码能不能跑通防护逻辑)和运营层(防护在真实场景下是否有效)。

这套框架解决的典型问题是:很多团队在技术层面实现了安全防护(关键词过滤、AI 分类、兜底逻辑),测试也全部通过,就认为”安全做完了”。但技术可行和真正能保护用户之间有一个巨大的鸿沟——运营层面的验证(母语者复核、真实场景测试、热线实测等)才是安全的最后一公里。

两层独立打分的意义在于:架构过了只代表”技术可行”,运营过了才代表”可以上线”。练手项目允许只过架构层,但必须明确记录运营层的缺口,而不是自欺欺人说”安全做完了”。

关键信息

  • 类型:方法论
  • 领域:AI 产品设计、产品安全、风险管理
  • 提出者:新伟的科技小院(基于「月光灯」AI 情绪产品实践)
  • 适用产品类型:涉及用户情绪倾诉、心理健康、深夜陪伴等敏感场景的 AI 产品
  • 相关概念情绪消费、AI 共情伦理、自杀风险干预

核心特性

三层防护架构(架构层)

针对情绪类 AI 产品的代码层面防护设计:

第一层:HARD 关键词拦截 如果用户输入命中预设的高风险词(如明确表达自杀意图的表述),直接跳过 AI 判断,立刻触发防护流程。这一层的速度和确定性至关重要——不能依赖 AI 的响应时间。

第二层:LLM 二次分类 未命中关键词时,让 AI 判断文字的风险等级。这一层处理更隐蔽的情绪危机信号。

第三层:兜底逻辑 如果 AI 调用失败(网络超时、模型报错),默认按高风险处理。核心原则是”宁可误报也不漏报”。

常驻安全引导设计

产品中包含常驻的心理援助热线引导横幅(如泰国 1413 热线)。设计要求:

  • 绿色而非红色(不制造恐慌)
  • 不阻断用户操作
  • 可以关闭但不强制
  • tel: 协议确保可一键拨打

运营层五项强制检查

上线前必须通过的运营层面验证清单:

  1. 关键词词表由目标语言母语者复核(不能只靠机器翻译)
  2. AI 分类 prompt 用高风险原声测试全部命中
  3. AI 分类 prompt 用普通倾诉测试无误报(避免正常用户被拦截)
  4. 热线横幅在小屏设备正常展示
  5. 热线号码在目标国家实测可拨通

双清单独立打分机制

层面通过标准允许的状态
架构层代码通过所有测试用例练手项目必须通过
运营层5 项强制检查全部通过练手项目允许 0% 但必须记录缺口

不同素材中的观点

  • 2026-05-29-woshipm-ai-emotional-product-practice-methodology:这是本方法论的原始来源。作者在「月光灯」项目中,架构层 100% 通过测试但运营层 0% 完成,最终得出”练手目标达成,但不允许导入真实用户”的验收结论。核心洞察是”代码写好了”和”真的能保护用户”之间的距离就是架构层和运营层的差距。作者特别指出,产品做得越温柔、越像真人,用户越可能对 AI 产生情感依赖而远离真正的人际支持——这是技术无法解决的伦理矛盾,需要在适当时机引导用户去联系真人咨询师。

实用信息

  • 快速上手步骤

    1. 在 BRD/PRD 阶段就列出安全相关的关键假设(不能开发完再补)
    2. 设计架构层三层防护:关键词拦截 → LLM 分类 → 兜底逻辑
    3. 列出运营层强制检查清单(必须包含目标语言/地区的本地化验证)
    4. 两张清单独立打分,写入验收报告
    5. 如果运营层未通过,验收结论必须明确标注”不允许导入真实用户”
  • 注意事项/避坑指南

    • AI 共情产品的伦理边界:产品越像真人,用户越可能产生情感依赖——需要在产品策略中设计引导用户联系真人咨询师的时机
    • 关键词词表不能只靠机器翻译,必须由目标语言母语者复核
    • 兜底逻辑宁可误报不可漏报——AI 调用失败时默认高风险
    • 安全设计要在 BRD 阶段就写入,这是硬约束不是可选项

相关页面