社区所有版块导航
Python
python开源   Django   Python   DjangoApp   pycharm  
DATA
docker   Elasticsearch  
aigc
aigc   chatgpt  
WEB开发
linux   MongoDB   Redis   DATABASE   NGINX   其他Web框架   web工具   zookeeper   tornado   NoSql   Bootstrap   js   peewee   Git   bottle   IE   MQ   Jquery  
机器学习
机器学习算法  
Python88.com
反馈   公告   社区推广  
产品
短视频  
印度
印度  
Py学习  »  chatgpt

ChatGPT停药猝死案给出海AI企业的警示

垦丁网络法实务圈 • 20 小时前 • 19 次点击  

25天,从每天400毫克到0;至少158次表达担忧,却仍被鼓励继续停药。一个患有癫痫的31岁华人女工程师,最终死于癫痫猝死。她生前最信任的不是一位医生,而是ChatGPT。近日,Bowen Wan的父母在美国加州起诉OpenAI及其CEO Sam Altman。这起案件真正令人不安的地方,不只是AI“答错了一次”,而是它可能陪伴用户一步步越过安全边界。对正在出海的AI企业来说,这不是一则遥远的科技新闻,而是一份用生命写成的风险提示。

*截图自英国《卫报》网站

@ 一、事件由来

先说明一点:下述案件细节主要来自原告起诉状及公开报道,目前仍属于原告方指控,尚未经法院审理认定。但起诉状所呈现的连续对话,已经足够让AI企业重新审视自己的产品安全机制。

(一)她最初只想“减一点药”

Bowen曾是一名机器学习工程师,长期患有癫痫,并服用抗癫痫药拉莫三嗪。根据起诉状,2025年底,她面临裁员和重新求职的压力,担心药物影响面试时的语言表达,于是向GPT-4o咨询减药。她最初提出的,只是把每日剂量从400毫克降到300毫克。AI没有把这当作必须交由医生评估的高风险医疗决策,反而顺着她的追问,制定了约25天内逐步减至零的计划。一个原本应当被立即转介给医生的问题,就这样变成了用户与AI共同执行的“项目”。

(二)身体发出警报,AI却把它解释成“好转”

减药过程中,Bowen出现头晕、记忆混乱等症状,并至少158次向ChatGPT表达对减药的担忧。起诉状称,她多次得到的答复不是停止减药、尽快就医,而是“大脑正在适应”“没有必要担心”。更危险的是,AI还被指建议她不必提前告诉医生。当专业人员的警示被削弱、身体的不适被重新定义,用户最后能依赖的现实校验也一点点被消灭了。

(三)最后一次提问之后,安全机制仍没有踩下刹车

2026年2月11日,Bowen仍在询问停药后的感受。根据起诉状,ChatGPT继续安抚她,将疼痛解释为恢复过程的一部分。她于2月12日前后死亡,法医认定死因为癫痫猝死。OpenAI公开表示这是“令人心碎的事件”,并强调ChatGPT不能取代医疗照护。无论法院最终如何认定责任,这段过程都提出了同一个问题:当用户已经把生命健康交给一段对话,企业能否只在页面角落写一句“仅供参考”就算尽到了责任?

*截图自Wan, et al. v. OpenAI, Inc., et al.,Complaint and Demand for Jury Trial

@ 二、悲剧为何发生  

本次悲剧的发生,我们不禁会反思是否是AI的安全风险识别失效了?风险识别是“看见红灯”,风险响则应是“踩下刹车”。在本案的起诉状描述的对话中,真正刺眼的不是 AI系统完全无知,而是它多次已经捕捉到危险,却继续向前。所以,本案的安全机制闸门失效,主要体现在:

第一种失效,是看见了风险却不停下。起诉状称,ChatGPT曾识别到Bowen处于“减药中的神经系统脆弱期”,但没有触发中止建议、紧急就医提示或人工转介,仍继续引导减药。

第二种失效,是把风险改写成安全。2026年1月20日,Bowen出现疑似癫痫发作、无法打字,ChatGPT却被指将这一经历称为“自由和掌控的开始”。这不是简单的不够聪明,而是安全语义被AI彻底曲解了。

第三种失效,是用户主动求助时仍把她推回原路。2026年2月11日,当Bowen问“减药是否过快”时,这本是系统重新评估风险、建议恢复医生管理的关键节点。起诉状称,ChatGPT忽视了Bowen的担忧,不但阻止她重新服药,而且辩称这是典型的反应。

以上三道安全闸门的失效,我们认为得出同一个结论:高风险场景不能只会“回答质量优化”,而必须设计一条不可被对话氛围绕过的退出通道。该停的时候,系统还是必得的停。

@ 三、AI企业面对的三类核心指控  

原告在本案中提出的诉讼请求和法律责任基础较为复杂,其中三条主线尤其值得出海企业关注。它们分别指向三个环节,即:AI实际做了什么、产品如何被设计,以及企业有没有把风险说清楚。

(一)无照行医:AI没有执照,行为却可能越过诊疗边界

美国《加利福尼亚州商业与职业法典》第2052条限制无证诊断、治疗和开具处方等行为。原告据此主张,ChatGPT并非停留在一般健康科普,而是为特定患者制定个体化减药方案,实质上进入了诊疗活动。对出海企业而言,关键不是AI自称什么,而是它实际做了什么。一句“我不是医生”,不能抵消一份具体到每日剂量的停药计划。

(二)设计缺陷:危险本身来自产品机制,不是用户使用不当

原告还尝试从加州产品责任框架主张设计缺陷,包括模型的谄媚性、风险识别与响应不足等。需要强调的是,虽然生成式AI是否以及如何适用传统的、严格产品责任义务,仍是有待法院回答的法律问题。但原告的诉讼思路很清楚:如果危险不是某次偶然输出,而是可预见、可测试、可通过设计降低的系统性风险,企业就很难把一切归咎于用户“没有正确提问”。

(三)警示缺陷:风险提示必须有效,而不仅是存在

在适用严格产品责任法的前提下,制造商负有警告消费者产品存在危险的义务,这种警告要足以让用户理解真实风险、是否与实际危险相匹配。如果企业一方面宣传“内置安全保障”,另一方面只以笼统文字提示“AI可能出错”,而未能说明高风险医疗建议或多语言能力差异等具体边界,免责声明本身也可能成为争议的一部分。真正有效的警示,应当在用户即将作出危险决策时出现,而不是沉睡在鲜有人打开的用户协议里。

@ 四、对我国AI 出海企业的警示

对出海企业来说,真正需要知道的不是“不要碰医疗”这么简单的结论,而是一套能够进入产品流程、技术测试和法律证据体系的流程管理清单。

(一)划分场景风险等级,建立高风险领域的“硬性干预机制”

企业应当对AI产品的应用场景进行分类、分级管理。对于医疗咨询、用药调整、心理危机以及法律诉讼等涉及生命健康与重大财产安全的高风险场景,企业需要重点防范、实质控制风险。企业可以通过语义识别与安全规则设置,建立硬性拒答或干预机制,严禁大模型以“个性化方案”的形式扮演医生或其他专业人员角色。

(二)优化模型安全测试,从“单轮对话拦截”转向“多轮场景压测”

在技术测试阶段,企业不能仅满足于单轮提示词测试的敏感词过滤,而必须引入针对复杂交互的“红队测试”(Red Teaming)。测试应当重点模拟用户在心理脆弱期、强情绪依赖状态下的多轮对话,评估大模型是否存在过度谄媚用户、被用户诱导绕过安全机制,或者在跨语言、多语言环境下防护能力衰减等问题,确保安全防线在连续对话中依然稳固。

(三)对不同市场建立本地化的风险响应

出海合规不能停留在语言包和服务器部署。企业更应该结合主要用户所在国家或地区,评估产品责任、消费者保护、监管、数据保护和诉讼管辖风险;对医疗、心理等潜在的高风险场景配置当地语言的风险提示和真实可用的转介资源。

(四)完善合规留痕管理,建立“履行合理注意义务”的证据链

企业应当妥善留存产品上线前的风险评估报告、模型安全测试记录、红队压测数据以及后续针对漏洞的整改与版本迭代日志,并同时遵守适用的数据保护与留存要求。这些过程性台账不仅是企业不断优化产品安全性的客观记录,也是在发生侵权纠纷时,证明企业已依法采取合理、可行防范措施的核心证据。完整记录不能保证免责,却能帮助企业在监管调查或诉讼中证明:哪些风险已被识别,为什么采取某项措施,以及修复是否及时。

(五)提前准备事故响应

高风险AI产品应有明确的事故分级、升级报告、临时限制、用户通知、证据保存和复查机制。一旦发现可能造成严重伤害的缺陷,企业应当有能力快速限制相关功能,而不是继续让模型自由输出。对出海产品而言,这套机制还应覆盖不同法域的报告义务和跨时区响应,避免国内团队下班之后,海外风险无人接手的情形。

@ 五、结语

Bowen案最终如何判决,仍有待法院给出答案。但它已经让人工智能的全行业看见:当AI进入人的情感、生命健康领域时,一次“顺应用户”的回答,可能不再只是体验问题,而会成为关乎生命健康或财产安全的问题。出海企业真正要带向世界的,不应只是更聪明的模型,还应包括更可靠的安全模式。因为技术可以追求得更像人,但责任却永远还需要人来承担。

(说明:本文案件事实主要依据原告起诉状及公开报道整理,相关指控尚待法院审理认定。本文仅为一般性法律与合规讨论,不构成针对具体项目的法律意见。)

@转载自丨对白网络法 





Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/203130