一次OTA把缺陷悄悄刷掉，算不算召回——软件缺陷、远程升级与召回责任的三个实务判断

#引言：一次没有公告的升级，和两个月后的一起事故

　　先说一个在智能网联汽车企业里越来越常见的会议场景。质量管理部报告：一批已交付车辆在雨夜场景下，前视摄像头与毫米波雷达的融合判断会偶发误识别，表现为车辆对前方静止障碍物的识别距离明显缩短，但复现率不高，售后只接到零星反馈。研发部门的方案很直接——下一版软件把融合阈值调高，通过OTA推给全部车辆，两周内解决。市场部松了口气：不用进店、不用拆件、不影响销量，连公告都不必发。

　　法务在会上问了三个问题，会议室安静了下来。第一，这算不算"缺陷"？如果算，我们这次推送的到底是"升级"还是"召回"？第二，如果只是推送了升级、没有按召回程序走，将来出了事故，这条路径会被怎么评价？第三，这个融合算法是外部供应商提供的，出了问题，成本最后由谁承担？

　　这三个问题之所以难，不是因为法条不清楚，而是因为汽车行业的软件迭代节奏，与缺陷召回制度所假设的"批次—型号—已售车辆—消除缺陷"这套逻辑，天生不完全咬合。软件可以一夜之间改掉，硬件不行；缺陷可以只在特定场景出现，批次却无法按场景切分；升级可以是功能增强，也可以是缺陷修复，两者在代码层面甚至就是同一个动作。

　　监管并不是没有看见这件事。2020年11月，市场监管总局办公厅印发《关于进一步加强汽车远程升级（OTA）技术召回监管的通知》（市监质〔2020〕123号），第一次把OTA明确纳入召回监管：生产者采用OTA方式对已售车辆开展技术服务活动要备案，采用OTA方式消除缺陷、实施召回的，要按《缺陷汽车产品召回管理条例》及其实施办法制定召回计划并备案；OTA未能有效消除缺陷或者造成新的缺陷的，应当再次采取召回措施。2025年2月，工业和信息化部、市场监管总局又联合印发《关于进一步加强智能网联汽车产品准入、召回及软件在线升级管理的通知》（工信部联通装〔2025〕45号），把OTA分成三类分别管理，并直接写明要"避免企业通过OTA升级隐瞒车辆缺陷或规避责任"。

　　再往前一步，2026年8月28日，市场监管总局（国家标准委）批准发布推荐性国家标准GB/T 48140—2026《汽车软件质量与缺陷管理规范》，自2026年12月1日起实施。这份标准覆盖汽车软件需求分析、设计实现、集成、验证确认、发布管理、升级与维护全生命周期，要求建立软件风险评估机制，并对采用OTA方式实施召回作出规定。它虽然只是推荐性标准，但它会成为判断企业"有没有尽到注意义务"的一把尺子——这一点，比它是不是强制，更值得企业重视。

　　下面三个判断，是我认为在当前规则下最需要提前想清楚的。

#一、把缺陷"刷"掉，是不是就不用走召回

　　很多企业的第一反应是：OTA不是召回，OTA是售后服务。

　　这个理解从技术直觉上说得通，在法律上站不住。《缺陷汽车产品召回管理条例》第三条把"召回"定义为：汽车产品生产者对其已售出的汽车产品采取措施消除缺陷的活动。定义的关键词是"消除缺陷"，不是"进店"、不是"拆件"、也不是"换件"。第十九条进一步规定，对实施召回的缺陷汽车产品，生产者应当及时采取修正或者补充标识、修理、更换、退货等措施消除缺陷。这里的"修正"，在软件定义汽车的时代，主要载体就是软件更新。

　　换句话说，判断一次OTA是不是召回，看的不是它用什么通道推送，而是它要解决的那个问题，是不是条例意义上的"缺陷"。如果是缺陷，那么无论推送得多安静、代码改得多小、用户感知得多弱，它在法律上就是召回，就要走召回的程序：向市场监管总局备案召回计划、以便于公众知晓的方式发布信息、告知车主缺陷内容和应急处置方法、提交阶段性报告和总结报告。

　　2025年那份通知把这一点写得更细。它按变更程度把OTA分成三类：不涉及产品主要技术参数变更的，完成备案后即可实施升级；涉及主要技术参数变更的，要取得产品变更许可并完成备案后才能实施；涉及汽车自动驾驶功能的，还要按准入管理有关规定取得相应许可。同一条里紧接着写：企业实施OTA升级活动消除汽车产品缺陷、实施召回的，应当按照《缺陷汽车产品召回管理条例实施办法》组织实施，并立即停止生产、销售缺陷汽车产品。

　　这里有一个特别容易被忽略的连带后果：如果消除缺陷的措施涉及产品主要技术参数变更，企业要在取得产品变更许可后，才能恢复相应汽车产品的生产。也就是说，"边生产边等软件修"这条路，在规则上是走不通的。生产线停不停，取决于缺陷有没有被消除，而不取决于软件什么时候写完。

　　那么"悄悄修掉"的风险到底落在哪？首先是行政责任。《条例》第二十四条规定，未停止生产、销售或者进口缺陷汽车产品、隐瞒缺陷情况、经责令召回拒不召回的，责令改正，处缺陷汽车产品货值金额1%以上10%以下的罚款，有违法所得的并处没收违法所得，情节严重的由许可机关吊销有关许可。请注意"隐瞒缺陷情况"是独立的一项，它不要求你拒绝召回，只要你知道了却不说、不报、不按召回走，就可能落进这一项。按货值比例计算罚款，对年销数万辆的车型来说，不是一个小数目。

　　其次是民事后果，而且往往比罚款更贵。《民法典》第一千二百零六条规定：产品投入流通后发现存在缺陷的，生产者、销售者应当及时采取停止销售、警示、召回等补救措施；未及时采取补救措施或者补救措施不力造成损害扩大的，对扩大的损害也应当承担侵权责任；依据前款规定采取召回措施的，生产者、销售者应当负担被侵权人因此支出的必要费用。《条例》第二十八条又补了一句：生产者依照本条例召回缺陷汽车产品，不免除其依法应当承担的责任。

　　这两条合起来的效果是：召回是义务，不是赦免。你召回了，该赔的还要赔；你没召回、只偷偷升级，那么"未及时采取补救措施"这个要件，几乎是被你自己写实的——因为内部一定有版本记录、有测试报告、有推送日志，这些都证明你在某个时间点已经知道问题存在。

　　但这条条文有一个极容易被读漏的地方，值得单独说一句。它追究的不是缺陷本身造成的全部损害，而是"损害扩大"的那一部分——也就是如果及时警示、及时召回本来可以避免、却因为拖延而没有避免的损失。这个限定对双方都是双刃剑。对企业来说，它意味着责任有边界，不必为缺陷本身承担无限后果（缺陷本身的责任走产品责任那条线，构成要件不同）；对受害人来说，它意味着必须把"本来可以避免的部分"从总损失里切出来，并且证明这个切分。这也是这类案件真正的战场：不是争有没有缺陷，而是争哪一段损害属于"扩大的"。

　　而这个切分，恰恰又回到企业的记录上。如果企业能证明自己在获知后第几天组织调查、第几天完成评估、第几天启动召回，那么"扩大"的时间窗口就很窄；如果企业只有一版悄然推送的软件、没有任何时间节点记录，那么从问题出现到事故发生之间的全部损失，都可能被认定为"本可避免"。所以留痕在这里不是形式主义，它直接决定赔偿金额的量级。

　　我的实务建议是，把"这次改动是不是缺陷修复"做成一道必须过的门，而不是由研发或市场单方判断。具体做法可以很朴素：在版本发布流程里加一张一页纸的判断表，回答四个问题——这次改动解决的是功能增强还是异常行为；异常行为是否涉及人身、财产安全；影响范围是全部车辆、某批次还是个别车辆；如果不推送，最坏后果是什么。四个问题答完，走哪条路径基本就清楚了。这张表要签字、要归档，因为将来它就是"你有没有及时判断"的证据。

#二、"普遍存在"这四个字，决定走哪条路

　　第二个判断，是很多人绕不过去的一道坎。

　　《条例》第三条对"缺陷"的定义有两层：一层是由于设计、制造、标识等原因导致的，在同一批次、型号或者类别的汽车产品中普遍存在的不符合保障人身、财产安全的国家标准、行业标准的情形；另一层是其他危及人身、财产安全的不合理的危险。第一层里"普遍存在"这四个字，在软件时代变得非常微妙。

　　一个只在特定雨量、特定光照、特定路面反射率下才复现的融合算法问题，算不算"普遍存在"？如果全国只有三辆车报告过，但它根植于所有装了同一版本软件的车上，那它是"个别现象"还是"批次问题"？监管在缺陷调查中看的，通常不是投诉数量本身，而是问题是否由同一设计或同一版本引入、是否会在同类条件下重现。这一点，企业如果只按"投诉量"自我判断，很容易判反。

　　这里必须做一个区分，否则后面的路径会全错：不构成《条例》意义上的"缺陷"，不等于企业什么都不用做。

　　原因在于，民事上的责任基础不止一条。《消费者权益保护法》第二十三条第一款要求经营者保证商品在正常使用情况下具备应有的质量、性能、用途和有效期限；第二款要求实际质量与广告、产品说明、实物样品表明的质量状况相符。软件升级后某项功能缩水、某个场景的表现反而变差，即使不构成行政意义上的缺陷，也可能构成质量不符，落进违约或者瑕疵担保的范畴。

　　同一部法律第十九条还规定：经营者发现其提供的商品或者服务存在缺陷，有危及人身、财产安全危险的，应当立即向有关行政部门报告和告知消费者，并采取停止销售、警示、召回、无害化处理、销毁、停止生产或者服务等措施；采取召回措施的，经营者应当承担消费者因商品被召回支出的必要费用。这一条的主体是"经营者"，不限于生产者，销售者同样被覆盖。

　　举证责任的分配，是这类纠纷里最实际的一条线。《消费者权益保护法》第二十三条第三款规定：经营者提供的机动车、计算机、电视机、电冰箱、空调器、洗衣机等耐用商品或者装饰装修等服务，消费者自接受商品或者服务之日起六个月内发现瑕疵，发生争议的，由经营者承担有关瑕疵的举证责任。六个月，从接受商品之日起算。这意味着，提车半年内出现的软件异常，举证压力在经营者一侧；超过六个月，消费者要自己证明瑕疵存在、且与产品本身有关。

　　而对OTA引发的争议来说，六个月这条线几乎必然被跨过——升级通常发生在购车一两年之后。此时消费者面对的是一个残酷的现实：代码、版本记录、测试报告、推送日志，全部在厂家手里。这也是为什么这类案件里，"申请法院责令对方提交其控制下的证据"往往比"自己去找鉴定机构"更有效；同时，车主自己能做的最有价值的事，是在问题出现的第一时间固定三类材料：车机上的版本号与升级提示截图、故障发生时的行车记录与时间戳、以及向售后报修的完整记录。这三样东西，决定了后面能不能把举证责任重新推回去。

　　几条路径的利弊，可以这样比：

　　走行政召回，优点是覆盖全部同批次车辆、有监管背书、消除缺陷的费用由生产者承担，且能形成对后续民事索赔的有利事实基础；缺点是周期长、要公开、对品牌和二级市场残值有直接影响，而且一旦启动就很难中途收手。

　　走保修或三包修理，优点是快、低调、客户体验好；缺点是它只能解决"这一辆车"，解决不了"同一版本的其他车"，而且如果问题实际涉及安全，用保修消化掉，事后可能被评价为"以修理替代召回"。

　　走协商补偿，优点是最灵活，可以按车给延保、给积分、给置换补贴；缺点是它不产生对外效力，其他车主不受约束，且补偿协议里如果写了"放弃后续主张"，容易被认定为不合理地免除经营者责任。

　　走诉讼，对单个车主来说成本高、周期长，但如果证据固定得好、且能证明缺陷与损害的因果关系，赔偿范围可以覆盖人身损害与财产损失，且《条例》第二十八条明确召回不免除责任。

　　我的建议是：不要把这四条路当成互斥选项。理性的组合通常是——先做技术判断确定影响范围，涉及安全的按召回走，不涉及安全但影响使用的按保修加统一补偿走，同时对已经发生的个别损害单独处理。最怕的是四条路都不走，只发一版软件了事。

#三、软件不是主机厂一个人的事

　　第三个判断，出在供应链上，而且往往是在出事之后才被发现。

　　《条例》第八条把"生产者"定义为在中国境内依法设立的生产汽车产品并以其名义颁发产品合格证的企业，从境外进口汽车产品到境内销售的企业视为生产者。这个定义很清楚：对外承担责任的主体，是那个在合格证上署名的企业。车主不会去找算法供应商，监管也不会。

　　但这不意味着供应商可以置身事外。2025年那份通知在"强化企业产品质量安全主体责任"一项里，要求汽车生产企业根据配套的技术指南，加强与研发生产智能网联汽车产品及开展OTA升级活动相适应的能力建设，对产品和OTA活动开展充分测试验证，明确系统边界和安全响应措施。注意"系统边界"这个词——它意味着主机厂必须真正理解供应商交付的那个模块在什么条件下会失效，而不是拿到一份"符合功能安全要求"的声明就签字。

　　新发布的GB/T 48140—2026把这一点推得更远。按市场监管总局的说明，这份标准要求汽车生产者、软件提供方及供应链上下游相关组织建立软件质量安全管理体系，实施软件安全管理、历史问题规避、状态报告监控等10项关键质量保证活动，并针对软件项目策划、需求分析、设计实现、软件集成、验证确认等5个关键过程设置评审节点。标准是推荐性的，但它描述的是"行业公认的应有做法"。一旦发生争议，"你有没有按这套做法建立体系"就会成为判断过错的重要参照。

　　现实中的合同，问题通常出在四个地方。

　　一是验收标准写成"符合国家强制性标准"。GB 44496—2024《汽车软件升级通用技术要求》是强制性国家标准，2024年8月23日发布、2026年1月1日实施，规定的是软件升级的管理体系要求、车辆要求、同一型式判定和使用说明书等内容；GB 44495—2024《汽车整车信息安全技术要求》同样是强制性标准，发布与实施日期相同。符合强制性标准是底线，不是全部。如果合同只写这一句，那么供应商交付的模块在真实场景下表现不佳、但并不违反强制性标准时，主机厂很难主张违约。

　　二是没有约定缺陷通知义务的触发点和时限。供应商往往在内部测试、客户支持、甚至其他车企的召回公告里最早发现问题。合同里如果只写"发现质量问题应及时通知"，"及时"两个字在诉讼中几乎无法执行。有效写法是把它具体化：发现或合理怀疑模块存在可能导致人身、财产损害的情形，应在多少个工作日内书面通知，通知应包含哪些技术信息，未通知造成扩大损失的部分由谁承担。

　　三是没有约定配合监管调查的义务。《条例》第十四条要求生产者配合缺陷调查，提供调查需要的有关资料、产品和专用设备；第二十三条规定不配合缺陷调查的，责令改正，拒不改正的处50万元以上100万元以下罚款。主机厂要履行这个义务，前提是它能从供应商那里拿到资料和代码说明。如果合同没写，到了监管要材料的时候，谈判地位是倒过来的。

　　四是召回成本的分摊没有约定，或者约定了但不可执行。召回成本不只是维修费，还包括车主通知、经销商工时、代步车、运输、以及品牌损失。比较务实的写法是按过错比例分摊，并事先约定一个可核算的口径（例如按单车工时乘以实际召回台次），而不是笼统写"由责任方承担全部损失"——后者在谈判时好看，在执行时往往因为无法举证过错比例而落空。

#四、律师视角：把"软件缺陷"做成一件可举证的事

　　讲完三个判断，回到最实际的一层：企业真正需要建立的，不是一套更漂亮的文件，而是一条能自证的链条。

　　《条例》第九条要求生产者建立并保存汽车产品设计、制造、标识、检验等方面的信息记录以及初次销售的车主信息记录，保存期不得少于10年；第十一条要求销售、租赁、维修汽车的经营者建立并保存相关信息记录，保存期不得少于5年。在软件时代，这两条的含义被大大扩展了：版本号、发布记录、测试报告、灰度推送名单、OTA备案材料、事件事故报告，都属于"应当保存"的范畴。保存的意义不在于应付检查，而在于当你需要证明"我在某年某月某日之前并不知道这个问题"时，拿得出东西。

　　2025年那份通知还建立了事件事故报告机制：企业获知其生产销售的智能网联汽车产品发生组合驾驶辅助系统失效导致功能退出等事件，或搭载组合驾驶辅助系统的车辆发生碰撞等事故的，要按要求向工业和信息化部、市场监管总局报告。这是一个有时间压力的动作，而且判断往往发生在深夜。建议把"谁有权判断是否构成应报告事件、谁签字、往哪个渠道报、多久之内报"写成一张值班卡，而不是留在一份几十页的预案里。

　　另外一个容易被忽略的数字对比，值得每家企业自己算一遍。市场监管总局2026年第2号通告显示，2025年我国共实施汽车召回190次、涉及车辆684.6万辆；其中实施远程升级（OTA）召回13次、涉及车辆175.6万辆，占全年召回总数量的25.7%。而同期接收企业报告的OTA升级是1904次、涉及1.4亿辆次。1904次升级，13次召回。这个比例未必说明有问题——绝大多数OTA确实只是功能优化——但它足以说明，监管为什么会专门写一句"避免企业通过OTA升级隐瞒车辆缺陷或规避责任"。对单个企业而言，值得把这组数字换成自己的：去年推了多少次OTA，其中有多少次改动了与安全相关的判断逻辑，有多少次走了召回程序。如果后两个数字是零，而第一个数字很大，那大概率不是没有问题，而是没有识别。

　　最后是时间表。GB/T 48140—2026 从2026年12月1日起实施，距今还有一个多月。推荐性标准不会直接产生行政处罚，但它会在三个场合发挥作用：缺陷调查中对"是否尽到应有注意"的判断、民事诉讼中对"是否存在过错"的判断、以及主机厂与供应商之间对"谁没做到"的判断。趁着还没施行，把软件风险评估机制、缺陷分级标准、OTA变更分类判断表这三样东西建起来，成本远低于事后解释。

#结语

　　软件定义汽车带来的法律问题，表面上是一个"升级还是召回"的名分之争，实质上是三件事：企业有没有在正确的时间点承认自己知道了一个问题；有没有按问题的性质选择正确的处理路径；以及有没有能力把这条路径上的每一步留下证据。OTA让修复变得极其便宜，也因此让"装作不知道"变得极其诱人——而这恰恰是规则最不打算放过的地方。

　　如果贵公司正在搭建OTA发布流程、处理一起软件相关的召回或投诉，或者需要重新审视与软件供应商之间的责任条款，建议在下一版软件推送之前，先把"这次改动是什么性质"这道门补上。

---

需要专业帮助？预约测绘，帮你梳理软件缺陷认定、OTA备案与召回程序的边界。