自动驾驶撞了人，究竟该找谁赔——智能网联汽车事故责任分配的三个实务判断

#引言：一辆没有驾驶人的车，撞人之后谁先开口

　　设想这样一个场景。某运营公司在城市开放路段投放了一批没有驾驶人的完全自动驾驶车辆，提供载人出行服务。某天清晨，其中一辆在通过路口时与一名横穿马路的行人发生碰撞，行人重伤。车辆属于运营公司，整车由一家车企生产，自动驾驶系统则由第三方供应商提供。交警到场后，运营公司的第一反应是"这是自动驾驶系统在开"，车企说"车已经交付，路测和运营都是运营方的事"，供应商说"我们只是提供软件工具，怎么用是客户的事"。伤者家属只关心一件事：先找谁把钱要回来。

　　过去几年，这类场景还停留在纸面推演，如今已经进入真实的纠纷处理环节。真正难的地方在于，它不能靠一句"侵没侵权"回答，而要拆成三个彼此独立、又相互牵连的问题：落到具体的被告席上，究竟是驾驶人、车辆所有人管理人，还是生产者销售者；在营运方先行赔付之后，能不能向真正的技术源头追偿；以及事故发生后，那几十秒的行车数据归谁、怎么调、能不能出境。这三层里任何一层判断失误，后续的索赔方案和谈判筹码都会走偏。

　　需要先说清楚现在的规则坐标。国家层面，《道路交通安全法》解决的是机动车事故的赔付顺序与过错分担；《民法典》侵权责任编的产品责任与机动车交通事故责任两章，解决的是缺陷与追偿；工信部、公安部、交通运输部《智能网联汽车道路测试与示范应用管理规范（试行）》（工信部联通装〔2021〕97号，2021年9月1日施行）管的是测试与示范应用阶段。地方层面，深圳是走得最早也走得最细的一档，《深圳经济特区智能网联汽车管理条例》2022年8月1日施行，2026年5月25日经深圳市人大常委会通过修改决定、2026年7月1日起施行的修正文本，把"驾驶人"与"车辆所有人、管理人"的责任按自动驾驶级别作了更明确的切分。规则不缺，难的是把它落到具体动作上。

#一、谁该站在被告席上：不是"车开的"就能免责

#规则：责任主体是按"自动化程度＋系统是否激活"切分的

　　深圳条例的思路值得其他地区参考。修正后的第五十三条把赔偿责任主体分成了两条线：智能网联汽车由驾驶人驾驶时，或者有条件自动驾驶的智能网联汽车在自动驾驶系统激活状态下行驶时发生交通事故造成损害，属于该智能网联汽车一方责任的，由驾驶人承担赔偿责任；而高度自动驾驶、完全自动驾驶的智能网联汽车在自动驾驶系统激活状态下发生事故造成损害，属于该车一方责任的，由车辆所有人、管理人承担赔偿责任。对应的违法处理也做了区分，第五十一条把有驾驶人情形下的处理对象定为驾驶人，把高度、完全自动驾驶激活状态下的处理对象定为车辆所有人、管理人。

　　这里有一个容易被忽视的前提：条例所说的三种类型——有条件自动驾驶、高度自动驾驶、完全自动驾驶，其具体划分按国家有关标准执行。现行依据是推荐性国家标准 GB/T 40429-2021《汽车驾驶自动化分级》，该标准2021年8月20日发布、2022年3月1日起实施。换句话说，"这辆车到底算哪一级"，不是一个可以随口主张的产品宣传话术，而是要回到标准去对应。

　　赔偿的资金顺序则由上位法锚定。《民法典》第一千二百零八条规定，机动车发生交通事故造成损害的，依照道路交通安全法律和本法的有关规定承担赔偿责任。《道路交通安全法》第七十六条则设定了先保险、后过错的顺序：机动车发生交通事故造成人身伤亡、财产损失的，由保险公司在机动车第三者责任强制保险责任限额范围内予以赔偿，不足的部分再按规定承担赔偿责任。

#风险：最常见的两种误判

　　第一种误判是运营方以为"车是系统开的，与我无关"。但在高度、完全自动驾驶激活状态下，条例恰恰把对外的赔付主体指向车辆所有人、管理人，运营公司作为所有人或管理人，很难靠"技术自动运行"把自己摘出去。第二种误判发生在受害方一侧，以为"既然是智能汽车，直接告车厂就行"。实践中，车厂往往以"缺陷未经证明"抗辩，而直接赔付责任的前置环节仍在车辆一方和保险。绕过近端主体去追远端生产者，可能在程序上就先吃了亏。

　　还有一层实务风险来自保险配置。深圳条例第二十八条把投保写成车辆登记的前置条件：除一般登记资料外，还要求车辆车载设备运行安全相关数据已按规定接入政府监管平台，并已投保机动车交通事故责任强制保险和机动车第三者责任保险；具有载人功能的智能网联汽车还应当投保机动车车上人员责任保险。保险缺位，等于把赔付压力全部压回运营方的现金流。

#实务建议

　　对运营企业来说，第一件事是把"级别—责任—保险"三者对齐：确认车辆实际对应的自动化级别，据此明确谁是名义上的责任主体，再按载人、载物等场景补齐交强险、三责险与车上人员责任险，而不要用普通商用车队的保险结构去套自动驾驶车辆。第二件事是留存驾驶模式与系统激活状态的可回溯记录，因为责任切分的关键事实正是"事故发生时系统是否处于激活状态、由谁在驾驶"。第三件事是在与车主、车队、乘客的协议里，把事故处置的配合义务、资料提供义务和费用垫付安排写清楚，避免事故发生时各方互相推诿。

#二、赔完之后，能不能回头找厂家

#规则：缺陷是打开追偿之门的钥匙

　　对外先赔，并不意味着终局责任就此落定。深圳条例第五十四条明确：智能网联汽车发生交通事故，因该车存在缺陷造成损害的，车辆驾驶人或者所有人、管理人依照第五十三条的规定赔偿后，可以依法向生产者、销售者请求赔偿。这条通道的实体依据在《民法典》产品责任章：第一千二百零二条规定，因产品存在缺陷造成他人损害的，生产者应当承担侵权责任；第一千二百零三条规定，被侵权人可以向产品的生产者请求赔偿，也可以向产品的销售者请求赔偿，销售者赔偿后有权向生产者追偿。

　　还有两条容易被忽略但分量很重的规则。第一千二百零六条规定，产品投入流通后发现存在缺陷的，生产者、销售者应当及时采取停止销售、警示、召回等补救措施，未及时采取补救措施或者补救措施不力造成损害扩大的，对扩大的损害也应当承担侵权责任；采取召回措施的，还应负担被侵权人因此支出的必要费用。第一千二百零七条进一步规定，明知产品存在缺陷仍然生产、销售，或者没有依据前条规定采取有效补救措施，造成他人死亡或者健康严重损害的，被侵权人有权请求相应的惩罚性赔偿。

#风险：追偿的三道坎

　　第一道坎是"缺陷"的证明。交通事故责任讨论的是"谁开车"，产品责任讨论的是"车本身有没有问题"，两者的事实基础并不相同。自动驾驶的输出是算法决策的结果，事故往往由感知、决策、执行中的某一环偏差引起，"算法缺陷"的认定与举证难度远高于机械故障，需要依赖技术鉴定与专家意见。第二道坎是数据与版本的可获得性。如果拿不到事故发生时实际运行的软件版本、参数与决策日志，追偿主张很容易停留在推测层面。第三道坎是召回与后续风险。一旦某一批次的系统被发现存在同类缺陷，企业面临的不只是单起案的赔偿，而是存量车辆是否停用、是否召回的连锁决策，处置不及时还可能触发"扩大损害"的加重责任。

#实务建议

　　对运营方而言，向生产者追偿的前提是证据先行：事故发生后应尽早固定车辆软件版本、系统日志、远程监控记录，并通过书面方式要求生产者提供与该版本相关的技术资料与说明。对生产者而言，需要建立缺陷发现后的快速响应机制——调查分析、如实报告、必要时停止生产销售并召回，这些动作既是法定义务，也是日后在"是否及时补救"这一争点上自证清白的依据。对双方来说，一份事前写好的技术与责任条款，比事后的争论更能省下成本：软件版本升级的通知义务、事故后数据与技术的配合义务、缺陷成立后的损失分担与召回费用安排，都应当在采购与合作协议中预先落定。

#三、那几十秒的数据，到底归谁、能不能调

#规则：留存是义务，调取有边界

　　自动驾驶事故的核心证据，是一段并不长的数据。深圳条例第三十七条要求，车载设备应当记录和存储车辆发生事故或者故障前至少九十秒的位置、运行状态、驾驶模式、车内外监控视频等数据，并保持数据的连续性和完整性，数据存储期不得少于三十日。第五十五条则明确，车载设备、路侧设备、监管平台等记录的车辆运行状态和周边环境的客观信息，可以作为认定交通事故责任的重要依据。

　　但数据的调取与流动并不是没有边界的。第四十七条要求相关企业制定数据安全管理制度和隐私保护方案，采取措施防止数据泄露、丢失、损毁，并将存储数据的服务器设在中华人民共和国境内，未经批准不得向境外传输、转移相关数据信息；第四十八条禁止利用智能网联汽车非法收集、处理、利用个人信息，采集与本车辆行驶和交通安全无关的信息，以及非法采集涉及国家安全的信息。放到更大的法律框架里看，《网络数据安全管理条例》《个人信息保护法》关于个人信息与重要数据出境的规定，同样会叠加适用。

#风险：证据灭失与合规越界，可能同时发生

　　对受害方和运营方来说，最大的现实风险是证据灭失。三十日不是一段很长的时间，事故后如果各方忙于推诿而未及时发函保全，等到想要调取时，数据可能已经被覆盖或轮转。反过来，企业一方的风险在于"救火式取材"：为了尽快查清事故原因，把包含人脸、车牌、轨迹的原始数据随意导出、共享给境外团队或第三方，可能同时踩到个人信息保护与数据出境的边界。这两类风险经常在同一场事故里同时出现——想快点拿证据的人越急，越容易越界。

#实务建议

　　事故处置中，第一动作应当是书面固定：立即向运营方、生产者发出保全与提供数据的通知，明确要求保全事故前后完整时段的数据及其载体，并保留通知送达凭证。第二动作是合规调取：由具备相应资质的主体，在必要范围内调取，对涉及个人信息的部分作去标识化处理，跨境提供前先完成合规评估。第三动作是把"数据可用"写进合同：在与车主、供应商、云服务商的协议里，约定谁负责留存、留存多久、事故后多久内提供、由谁承担合规出境的判断责任，把这些条款前置，比事后逐一交涉高效得多。

#四、出事了，律师通常会让当事人先做这几件事

　　把前面的规则收拢成一套可执行的动作，顺序大致是这样的。首先是现场与报警，有驾驶人的按条例要求停车、保护现场、抢救伤员并迅速报警，无驾驶人的则由当事人立即报警，车辆所有人、管理人保存事故过程信息。其次是数据固定，用书面方式要求相关方保全并不得删除事故前后至少九十秒的行车与视频数据，同时核对其是否符合连续性与完整性要求。第三是保险报案与垫付，按交强险、三责险、车上人员责任险的顺序启动，避免资金链在关键时点断裂。

　　接下来才是责任主体的判断与证据链构建：确认事故时车辆所处的自动化级别与系统激活状态，锁定所有人、管理人与使用人，评估是否存在产品缺陷的初步迹象。若涉及缺陷争议，尽早委托有资质的技术鉴定并引入专家意见，避免在"算法缺陷"这一争点上被动。最后是条款层面的复盘——把本次事故暴露出的数据留存、技术配合、召回响应与损失分担问题，回填到采购与运营协议里，让下一次事故的处理成本更低。

#结语

　　自动驾驶带来的困惑，很多时候不在于技术有多新，而在于责任的链条被拉长了。一辆没有驾驶人的车，背后站着运营方、生产者、软件与数据服务的提供者，每一环都倾向于说"我只是链条上的一环"。规则给出的答案恰恰相反：对外赔付的主体，会随着自动化级别和系统激活状态落到具体的人身上；产品缺陷一旦成立，先行赔付方可以依法回头追偿；而支撑这一切判断的行车数据，既有强制留存的义务，也有调取与出境的边界。真正决定结果的，往往不是事故本身有多复杂，而是各方在事故之前的准备有多少。

　　如果您正在评估自动驾驶车辆的运营合规、事故责任分配，或者在数据留存、保险配置与企业间责任条款上拿不准，建议在车辆投放之前先把责任链条和数据方案一次性理清——这比事故发生后在高额索赔与举证拉锯之间周旋，要便宜得多。

---

遇到自动驾驶交通事故不知先找谁、该保全哪些数据？预约测绘，帮你厘清责任主体、追偿路径与证据固定方案。