现在大量AI产品并不是从基础模型开始自行训练，而是在OpenAI、Anthropic等商业模型API，或者各种开放模型的基础上继续开发。如果最终AI应用造成损害，一个很现实的问题是：应用开发者对外承担责任之后，能不能进一步向上游基础模型提供者追偿？

这个问题不能一概而论。本文认为至少需要区分三种供应关系：商业大模型API、商业主体提供的开源模型，以及免费、非商业提供的自由及开源软件（Free and Open-Source Software，FOSS）。

新版欧盟《产品责任指令》（Product Liability Directive，PLD）已经生效，但其新规则适用于2026年12月8日之后投放市场或投入使用的产品，因此下面讨论的是即将适用的新PLD框架。

欧盟新版PLD已经开始尝试把这种上下游AI供应链纳入产品责任框架；中国最高法2026年发布的《关于依法审理涉人工智能纠纷案件的意见》（以下简称《意见》）则没有建立一套对应的“基础模型组件责任—下游追偿”规则，更多需要回到各主体的过错、共同侵权以及上下游合同关系来判断。

一、商业大模型API：欧盟已经建立“组件责任+追偿”的基本路径

假设A公司调用B公司的商业大模型API，开发了一款医疗AI。由于B提供的基础模型本身存在缺陷，A开发的医疗AI作出了危险判断，并最终造成患者人身损害。

1. 欧盟PLD：上游模型可能成为“组件制造商”

PLD首先把software明确纳入“product”的定义，同时将component（组件）定义得非常宽，可以是有形的，也可以是无形的，只要被集成进产品或者与产品互联。因此，通过API与下游AI产品连接的基础模型，在符合具体条件时可能被认定为一个软件组件。PLD对component的关键定义是：

Article 4(4):‘component’ means any item, whether tangible or intangible, raw material or related service, that is integrated into, or inter-connected with, a product;

中文可以理解为：“组件”是指任何被整合进产品或者与产品相互连接的项目，不论其为有形或无形，也包括原材料和相关服务。

PLD还把制造商授权或同意第三方组件与产品进行集成、互联的情况纳入“manufacturer’s control（制造商控制）”的范围。

在此基础上，Article 8进一步建立了组件制造商责任。其关键表述是：

Article 8(1)(b):“the manufacturer of a defective component … caused that product to be defective”

中文含义是：如果一个存在缺陷的组件，在最终产品制造商控制下被集成或连接到产品中，并导致最终产品存在缺陷，该组件的制造商也可能承担PLD责任。

与此同时，最终产品制造商本身不会因为问题来自上游组件而当然免责。也就是说，如果B的基础模型存在缺陷，而A在自己的控制下将该模型接入最终AI产品，最终可能出现A和B同时成为责任主体的情况。

PLD Recital 53对此表达得很明确：当缺陷组件导致最终产品造成损害时，受害人应当可以同时向最终产品制造商和缺陷组件制造商寻求赔偿，并且两者可能承担连带责任。

A赔偿以后，可以向B追偿吗？

原则上可以。根据PLD Article 14Right of recourse（追偿权）：

Article 14:“has compensated the injured person … pursue remedies against other economic operators”

中文含义是：如果多个经济运营者对同一损害承担责任，其中一个经济运营者已经赔偿受害人，可以按照成员国国内法向其他依据Article 8承担责任的经济运营者追偿。

因此，如果A首先向患者赔偿，而B确实属于Article 8意义上的缺陷组件制造商，A原则上可以根据Article 14并结合成员国国内法向B追偿。

需要注意的是，A不能仅仅证明“B的模型回答错了”。它仍然需要把问题从一次错误输出推进到模型软件本身存在PLD意义上的缺陷。正如我们在之前文章所讨论的，PLD明确区分software与information：AI软件可以是产品，但单独一条生成信息本身不是产品。因此，“幻觉”只是事实起点，并不会自动形成上游产品责任。

另外，PLD主要保护自然人受到的特定损害，例如人身伤害、特定财产损失和特定数据损害。纯粹经济损失本身不触发PLD责任。因此，“医疗AI错误导致患者受伤”比较容易进入上述框架；“法律AI编造判例导致公司损失10万欧元诉讼费”则不能仅依靠PLD解决。

2. 中国：没有对应的“基础模型组件责任”规则

中国最高法《意见》目前没有建立类似PLD Article 8的“基础模型作为组件—组件提供者承担产品责任”制度。（虽然只是意见而非法律法规或者司法解释，我们也对比讨论一下）

本文发现，对于没有实物载体的AI应用，原则上首先还是按照《意见》第（三）项判断开发者、提供者等相关主体是否存在过错。《意见》的核心规则是：“法律没有明确规定适用无过错责任或者过错推定责任的，应当……适用过错责任原则。”

在具体判断过错时，法院还要考虑AI应用场景、自主化程度、技术和信息透明度、潜在风险，以及开发者、提供者采取了哪些预防措施、技术上能够采取哪些措施等因素。因此，如果A的医疗AI造成损害，错误确实源自B提供的基础模型，并不意味着A当然承担全部责任，也不意味着B当然承担责任。法院仍需要分别考察A和B各自能够控制什么、应当预见什么，以及有没有违反各自的注意义务。

如果A和B依法构成共同侵权或者其他连带责任情形，A对外承担超过自己责任份额的赔偿以后，可以依据《民法典》第178条追偿。但这里有一个关键前提：A和B必须先构成法律意义上的连带责任人。仅仅因为B是A的基础模型供应商，并不会自动产生连带责任。《民法典》第1168—1172条需要进一步区分共同侵权、分别实施但均足以造成全部损害，以及能够区分各自责任大小等不同情形。因此，在中国商业API场景下，真正更可控的内部追偿机制往往来自A和B之间的合同。

最高法《意见》第（十五）项明确规定：“应当根据合同约定，充分考量人工智能技术研发特点、技术开发方是否尽到合理努力等情形依法认定违约责任。”因此，商业基础模型API合同里的模型性能保证、适用场景、已知风险披露、版本变更通知、赔偿条款、责任上限以及证据配合义务，都会直接影响A最终能否向B追偿。

但笔者承认，在现实中，许多中小企业接入第三方大模型时只能接受平台预先拟定的格式合同，往往缺乏实质性的合同谈判空间。模型提供者通常会通过免责声明、责任上限、用途限制等条款尽可能控制自身风险，这意味着，“通过合同重新分配上下游责任”在理论上成立，但对议价能力较弱的应用开发者而言，实际能够通过合同获得多少追偿保障，往往取决于平台既有条款，而不是双方真正协商形成的风险分配。

当然，合同自治也并非没有边界。如果格式条款过度免除模型提供者自身责任、明显加重下游开发者责任，或者实质性限制对方的主要权利，相关条款本身仍可能受到司法审查；如果这种责任分配长期形成明显失衡，并演化为行业性问题，也不排除监管规则进一步介入，对基础模型提供者与下游应用开发者之间的责任边界作出更明确的要求。

二、商业主体提供的开源模型：开源并不等于免责

第二种情况是：B并不是通过封闭的商业API提供模型，而是以某种开源方式发布基础模型，但B本身是商业企业，或者这次提供行为本身属于商业活动。

1. 欧盟：真正决定是否适用PLD的，两个因素：“开源”和“非商业”

PLD Article 2(2)确实对FOSS设置了特殊排除：

Article 2(2):This Directive does not apply to free and open-source software that is developed or supplied outside the course of a commercial activity.

中文含义是：PLD不适用于在商业活动之外开发或提供的自由及开源软件。

换言之，“FOSS”本身还不够，必须同时满足开发或提供发生在商业活动之外。

PLD Recital 14对此进一步解释：软件如果收取价格提供，或者以超出安全性、兼容性、互操作性改善需要的个人数据作为对价，就属于商业供应，PLD应当适用；免费放在公共代码仓库也不当然构成商业供应，但如果这种提供本身发生在商业活动过程中，也可能不属于FOSS。

所以，一家商业模型公司即使采用开源许可证发布模型，如果该模型本身构成其商业业务的一部分，例如通过收费企业服务、托管部署、API、支持服务等方式实现商业化，也不能仅凭“开源”标签当然排除PLD的适用。

因此，对于产品责任承担，在满足Article 8其他条件的情况下，这种模型仍可能成为下游产品的缺陷软件组件，上游模型提供者仍可能承担责任，下游应用开发者赔偿后也仍可能依据Article 14追偿。

欧盟还有一个特殊的小企业例外

PLD Article 12(2)允许一种比较特殊的合同安排：如果缺陷软件组件的制造商在该组件上市时属于微型企业或者小型企业，并且下游制造商事先通过合同同意放弃追偿权，那么下游制造商不能再向这个软件组件制造商追偿。

但这个合同只能影响上下游之间的内部追偿，不能剥夺最终受害人的PLD权利。Article 15明确禁止通过合同排除或者限制经济运营者对受害人的法定PLD责任。

2. 中国：开源只是责任判断因素之一

最高法《意见》第（十三）项专门处理AI开源软件责任，但并没有规定“开源即免责”。法院应当结合开源协议、权利限制、安全合规和信息披露等因素判断责任。《意见》进一步给出了一个比较具体的免责场景：开源软件开发者、提供者以免费开源的方式提供涉人工智能软件研发所需要的部分代码模块，并公开说明其功能和安全风险，他人使用该代码模块导致侵权的，人民法院可以认定开源软件开发者、提供者不承担侵权责任。简而言之：商业化开源并不会自动取得这一特殊豁免。

如果B虽然开放模型，但实际上通过这一模型开展商业经营，或者没有充分披露模型的功能、已知局限和安全风险，仍然需要根据其具体过错以及与A之间的合同判断责任。如果A与B共同构成侵权，则可能进一步适用共同侵权和连带责任规则；如果主要是B违反双方约定，则A也可以沿合同违约路径要求赔偿。

因此，在中国，商业开源模型与商业API的责任结构大概是：开源许可会影响注意义务和责任判断，但并不会当然切断下游追偿。

三、免费、非商业FOSS：上游开发者可能直接退出产品责任链条

第三种情况才真正改变前面的答案。

假设一个独立开发者或者非营利研究团队，把一个AI组件以真正的FOSS方式免费公开，允许用户使用、研究、修改和再分发，并且这种开发和提供本身不属于商业活动。之后，A公司将该组件集成进自己的商业AI产品并向市场提供服务。

1. 欧盟：PLD明确把这类上游FOSS开发者排除在适用范围之外

如前所述，PLD Article 2(2)规定，在商业活动之外开发或提供的FOSS不适用PLD。Recital 15专门处理了后续商业化的情况：如果这样的非商业FOSS后来被一家商业制造商作为组件集成进产品并投入市场，下游商业制造商仍然需要对该软件缺陷导致的损害承担责任，但原来的非商业FOSS开发者不会因此重新进入PLD责任体系。

举个例子，如果A把一个真正的非商业FOSS模型组件拿来做商业医疗AI，后来因为这个组件的缺陷造成患者损害，A不能简单说：“真正出错的是上游开源模型，所以我要按照PLD找原开发者追偿。”

在PLD体系下，原来的FOSS开发者可能根本不是Article 8意义上的责任主体，因此Article 14的法定追偿路径也就没有相应的上游对象。

这是PLD有意作出的风险分配选择：谁把非商业开源软件带进商业产品市场，谁原则上要承担商业化所产生的产品责任风险，而不是把这种风险重新压回免费开源社区。

当然，这并不意味着开源开发者在任何法律制度下、任何情况下都绝对免责。PLD Article 2(4)明确保留成员国其他合同责任或者非产品缺陷基础上的侵权责任制度。因此，如果存在故意欺诈、其他独立违法行为等，仍要看成员国其他法律。

2. 中国：也存在明显保护免费开源开发者的司法政策

如前所述，中国最高法《意见》第（十三）项给出具体的免责场景：如果上游开发者免费开源AI软件开发需要的代码模块，并且已经向下游公开说明其功能和安全风险，之后下游企业自行使用该代码导致侵权：法院可以认定原开源开发者、提供者不承担侵权责任。

因此，如果A把这样一个免费开源组件商业化以后造成损害，B已经符合上述豁免条件，那么A即使对外赔偿，也未必能够通过侵权追偿把损失重新转嫁给B，因为B本身可能并不承担侵权责任。

四、总结

总的来说，中欧其实形成了一个很有意思的共同趋势：法律并不因为软件“开源”就自动减轻责任，真正受到特殊保护的是免费、非商业、并且以较充分的信息披露方式参与开源生态的开发者。相反，一旦企业将基础模型或开源软件纳入商业产品链条，商业化主体通常很难把最终产品的风险全部重新转嫁给上游开源社区。

但两边的法律技术不同。欧盟PLD已经明确把AI供应链“产品化”：软件是产品，无形软件可以成为组件，缺陷组件制造商可以与最终产品制造商同时承担产品责任，并设有明确的法定追偿规则。中国目前没有建立这样一套AI组件责任制度，而是通过过错责任、共同侵权、连带责任以及上下游合同来分配基础模型提供者与应用开发者之间的风险。

因此，对于企业真正的实务问题——“用了第三方基础模型以后，出了事能不能找模型公司赔？”——欧盟首先要问的是：上游模型是否构成缺陷产品或缺陷组件，并属于PLD责任主体；中国则更可能先问：上游提供者是否存在过错、是否与下游构成共同或连带责任，以及双方合同到底如何分配这一风险。

声明：本文来自数据合规与治理，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。