AI责任谁买单？——AIGC生成与传播中的责任边界

如您希望下载PDF版本，请点击文末“阅读原文”获取。

随着智能体由封闭的问答工具走向开放的搭建和分发平台，AI产品也正在经历类似于传统网站从“自建机房”走向“云端+多服务商”的演化。面对由模型、算力、知识库、搭建工具、存储空间和用户界面共同组成的智能体，已不能只用一个笼统的“平台责任”概括所有问题。

在这样一个多元、分工的AI生态下，模型开发者可能只提供基础模型，平台可能提供搭建工具和运行环境，智能体搭建者则可能负责选择模型、设置提示词、接入知识库并决定服务对象。

笔者认为，为了让针对多样生成式AI产品的法律规则真正可运行，有必要在三个层面上做精细对应，将每一项义务与产品中的特定行为对应，以精确覆盖具体行为，避免概括性地将所有技术提供者、管理者一并纳入共同侵权：

• 功能层面：先拆分出不同的技术功能模块，而不是把AI产品视为一个不可分割的整体。

• 行为层面：把每一项法律义务，具体对应到特定的技术行为或服务环节。

• 主体层面：在不同功能、行为之上，进一步识别是谁在控制和决策，避免因为“技术上有参与”就一概认定为内容提供者或共同侵权人。

这一分析方法并不意味着同一主体只能具有一种法律身份。个案中，被控侵权人同时参与了训练、生成、传播多个环节，也应当对其在不同阶段的具体行为加以区分。这不仅关乎责任边界的合理划定，也直接影响判决能否被执行，以及法律规则能否在未来产品形态不断变化的情况下保持抽象性与普适性，而不至于因为产品主体或结构的小改动就完全失效。

在展开具体分析之前，有必要首先明确本文所讨论的“AI智能体平台”的法律内涵与外延。本文所称的AI智能体平台，是指为智能体搭建者提供模型接入与调度、知识库挂载、工作流编排及运行环境托管等底层技术服务，并向终端用户提供统一交互入口的平台。AI智能体平台典型的商业与技术形态，既包括部署于公有云环境的互联网智能体平台，亦包括可供用户本地化部署的开源或商用智能体技术框架。 在运行逻辑上，AI智能体平台侧重于提供技术框架与运行环境；智能体搭建者负责具体技能配置、提示词设定及知识库上传；终端用户则在彼此隔离的独立数据空间内完成与智能体的一对一交互。技术提供、定制运营、终端使用的三层运行逻辑，以及用户数据空间的天然隔离性，是下文对多主体责任分层界定的技术事实前提。

1. 三类基础功能模块

现实中的AI产品形态多样，但从责任边界分析的角度，可以先抽象出三类基础功能：

三类功能可能由同一经营者同时提供，也可能分别由模型提供者、云服务商、智能体平台和搭建者控制。因此，某一主体参与了AI产品运营，并不当然意味着其对所有功能和全部内容具有相同程度的控制。

2. 不同AI产品是上述功能的不同组合

在前述功能分层基础上，可以进一步观察几类常见产品：

上述产品不是五种固定的责任类型，而是三类基础功能的不同组合：基础模型通常更接近技术组件，API和对话式服务可能在生成能力之外增加不同程度的存储和交互功能，传统应用和智能体平台则可能把AI生成能力接入既有的内容展示、推荐和用户服务体系。因此，对某项服务作法律评价时，通常不宜只看产品名称或者整体形态，而应进一步确认被诉内容在哪个环节产生、由谁决定，以及以什么方式到达用户。

智能体的名称、头像、背景图和简介等基本信息，通常会显示在详情页、列表页或者智能体广场中。对于这类内容，可以先区分两个阶段：

两个阶段在技术上可能连续完成，但行为主体、服务属性和适用规则未必相同：在生成阶段，需要重点考察谁控制输入、模型和生成逻辑，并从间接侵权和实质性非侵权用途的角度评价生成服务；当搭建者从候选结果中作出选择并确认发布后，内容进入存储和传播环节，则需要进一步判断平台是否主要提供信息存储空间，以及能否适用避风港原则。同一平台先后参与两个阶段，并不意味着两个阶段必须采用同一种责任规则。下文将据此分别展开。

1. 生成阶段：AI服务的SaaS特征的影响

在一种典型结构中，平台把模型和算力部署在云端，搭建者通过界面或者接口远程调用。AI服务自动处理输入并返回候选结果，平台并不针对每一次调用人工决定具体输出。在这种情况下，服务的技术形态可能更接近SaaS：用户调用的是远程运行的模型和计算能力，而不是平台预先编辑并持续向公众推送的内容。

更直白地说，这类似于用户远程调用一套已经部署好的Photoshop或者Word完成计算和创作：平台提供软件和运行能力，但具体输入什么、制作什么以及是否使用相关结果，主要由调用者决定。

不过，SaaS属性只是判断服务角色的一个考虑因素起点，最终责任仍需结合以下因素判断：

• 平台还是搭建者决定了提示词、知识库和使用场景；

• 平台是否提供了指向特定权利客体的默认模板或者固定指令；

• 平台是否对候选结果进行选择、编辑或者推荐；

• 平台是否通过产品设计或者宣传引导用户生成特定侵权内容。

如果具体内容主要由搭建者的指令和选择形成，平台又只提供通用计算能力，则不宜仅因平台参与了技术计算，就直接把每项输出都视为平台主动提供的内容。反之，如果平台对生成目的、内容范围或者输出方式具有较强控制，评价可能有所不同。

2. 不能仅凭“AI生成”概括所有主体的行为

智能体可能同时调用多个模型或者第三方服务。模型开发者、部署者、智能体平台和搭建者对具体输出的影响并不相同。

传统框架下的避风港规则以服务方在信息传播过程中对内容形成的参与程度，将网络服务提供者大致区分为服务提供者（ISP）与内容提供者（ICP）。“删除、屏蔽、断开链接"等必要措施，指向的是阻止侵权内容的持续传播，旨在赋予权利人及时制止损害扩大的救济途径。如果采用“只要对内容形成有技术影响，就属于内容提供者”的标准，基础模型开发者可能需要对所有下游场景中的具体输出负责。这种判断未必能够反映不同主体对内容的实际控制，也可能弱化最终选择、使用和发布内容的一方应当承担的核验义务。尤其在虚假宣传、商业诋毁等场景中，企业或者经营者不能仅以“内容来自AI”为由，把本应由其承担的真实性核验义务全部转移给技术提供者。

如果仅仅因为争议内容是"通过AI生成"而将AI能力提供者直接纳入ICP，将带来两方面问题：

（1）与AI行业的多主体分工模式不匹配

在现实的智能体生态中，某个智能体完全可能在一次服务中调用由不同的开发者、训练者和部署者运营的多个模型；生成内容的形成机制亦高度复杂，既受用户输入影响，也受训练数据与算法机制影响，还可能掺杂小概率随机因素；若沿用“谁对内容形成有客观影响，谁就是内容提供者”的判断标准，则任何使用某模型生成的输出，理论上都要视为该模型开发者或训练者“生产”的内容。

这意味着：即便开发者、训练者既不知情也无法预见某一搭建者的具体场景和使用方式，也理应对该搭建者在其自有业务中使用模型所产生的所有争议内容兜底承担ICP责任，显然与行业分工现实不相称。

（2）会在无形中削弱AIGC用户自身的注意义务

在虚假宣传、商业诋毁等非著作权场景中，信息使用者通常被期待承担较高的注意义务。如果简单将AI生成结果视为服务提供者“对外发布的内容”，那么与自行撰写文案相比，用户的注意义务势必被削弱；同时，责任更多转移给技术提供者，要求其对生成内容的真实性、合法性“背书”，而这是技术上难以实现的。 在极端情况下，用户甚至可能将“信息来源于AI”作为免责或减责理由，把本应由其承担的验证义务完整外包给服务提供者。

此外，从现有关于AI生成物权属的讨论实践来看，理论与实务界大多只在用户与AI服务方之间讨论“作品是否可受保护”“由谁享有权利”，鲜有把模型开发者或模型训练者纳入共同权利人的考虑范畴。这意味着各方普遍默认AI生成物体现的是操作者（用户）的意志，而非开发者、运营者的主观意志。若在确定责任层面因技术参与而一概将其视为ICP，则与这一隐含共识也存在内在矛盾。

因此，技术参与只是判断因素之一，还需要进一步确认谁确定了使用目的，谁控制了输入和配置，谁最终决定使用或者发布相关内容等因素。避风港原则并不直接用于评价一项生成工具本身是否侵权。在内容尚停留于按需生成、尚未进入后续传输和传播环节时，更适合从间接侵权及实质性非侵权用途的角度进行评价；当搭建者选定内容并将其发布到平台后，才进一步进入避风港规则所调整的范围。

（3）从“间接侵权”视角审视生成阶段的责任

进一步来看，前述主体区分也会影响生成阶段的责任性质。在部分生成式AI争议中，原告与被告都无法访问其他用户的生成内容，原告往往是在被诉服务中自行输入指令，使系统生成具有侵权性质的结果。此时，相关证据首先说明的是“AI具有输出某类内容的能力”，而不当然说明被告此前已经向其他用户实际生成或者交付过相同内容。

因此，这类主张在很大程度上更接近于对“提供侵权工具或者平台”的间接侵权指控，需要进一步判断相关服务是否具有“实质性非侵权用途”。其中至少有两点值得考虑：

• 生成内容具有一定不稳定性，不同指令、参数和生成次数可能产生不同结果，个别输出未必能够代表服务的通常运行状态，甚至可能是原告在多次尝试、努力后的偶发结果；

• 对于尚未投入后续使用或者传播的生成内容，还需要结合其具体使用目的和方式判断是否已经构成侵权，不能仅凭系统能够生成相关内容就直接评价服务整体。

在此前提下，如果一项服务整体上具有广泛、明显的非侵权用途，即使存在少量被用于侵权的个案，通常也不宜仅凭个别输出就认定服务本身构成间接侵权。只有在以下情形中，服务的整体性质和提供者的责任才可能发生变化：

• 服务提供者在通用模型基础上，针对特定侵权对象或者特定侵权类型进行专门微调、训练或配置，明显提高输出侵权内容的概率；

• 服务的功能设计、默认配置或者宣传方式，客观上引导用户以侵权方式使用该服务，甚至把获得侵权结果作为主要卖点。

在这些特殊情形下，相关服务可能难以再以实质性非侵权用途排除间接侵权责任。反之，对于以通用办公、创作辅助、知识问答等为主要用途，且未针对特定权利客体进行侵权导向设计的生成式AI服务，则不宜仅因其具备生成争议内容的能力，就直接认定服务本身侵权。

（4）存储/展示：信息存储空间服务与避风港原则

当搭建者从候选内容中选定某一头像、背景图或者文案，并通过管理端确认发布后，相关内容通常会被保存在应用层服务器，并在详情页或者列表页中展示。在这一阶段，搭建者的角色更接近传统平台中的上传者或者发布者：其从候选结果中作出选择，并决定将相关内容向访问者公开。平台则为搭建者提供可配置的存储空间和访问接口，保存并展示搭建者确认发布的内容。从主体分工看：

• 搭建者在两个阶段承担双重角色：在生成阶段，其是模型和生成服务的调用者；在存储与展示阶段，其又是候选内容的选择者和发布者；

• 平台则需要根据其在生成、存储和展示各环节中的实际参与程度，分别判断服务属性和责任边界。

如果具体内容确由搭建者选择和发布，平台在这一阶段的服务可能更接近信息存储空间服务。此时，平台对相关内容的责任边界可以适用避风港原则以及通知、必要措施等机制：平台在接到包含侵权初步证据的有效通知后，应当根据服务类型，在合理范围内采取删除、屏蔽、断开链接等必要措施；平台知道或者应当知道搭建者利用其服务侵权而未采取必要措施的，也可能承担相应责任。

由此，平台在前一阶段提供过AI生成能力，并不当然改变其在存储与展示阶段的服务属性，也不应仅据此将平台一概视为内容提供者。反之，如果平台对争议内容进行了选择、编辑或者重点推荐，或者已经知道、应当知道相关侵权风险，具体责任仍需另行判断。

综上，通过在生成阶段与存储/展示阶段之间做功能切分，可以较为精确地界定不同主体在智能体基本信息侵权中的法律角色。

与头像、简介等基本信息不同，实时回复通常在终端用户提出问题后才产生。智能体可能按照搭建者设置的模型、提示词、知识库和工作流生成答案，并把结果发送到用户的会话界面。这类内容与基本信息存在两个常见区别：

对于实时回复，可以依次从三个层面展开分析：先确认平台、搭建者和终端用户分别控制哪些生成要素；再确认内容仅向特定用户交付，还是可以被公开、分享或者推荐；最后结合通知内容、平台是否知道或者应当知道、控制能力和技术可行性，确定平台需要采取的措施。

下文主要讨论一种常见的智能体平台结构：平台统一提供搭建界面、运行环境、模型或第三方AI服务的接入能力，以及面向终端用户的访问入口和交互界面；搭建者在这一框架下选择模型、设置提示词、配置知识库、工作流和上下文记忆，并运营具体智能体；终端用户则通过平台入口与某个智能体进行一对一交互，生成结果仅进入该用户的独立会话空间。

在这种结构中，平台为多个搭建者提供通用技术框架和托管空间，搭建者在各自管理的智能体空间内向用户提供具体服务，类似于电商平台或者小程序平台提供统一的技术和访问入口，由经营者配置并运营具体店铺或者应用。因此，在生成阶段，平台可能更接近以SaaS方式提供模型接入和运行能力；在回复发送阶段，则可能更接近自动接入或者自动传输服务。

以上判断仍以具体架构和运营事实为前提。如果平台直接决定智能体的业务目的、提示词、知识库或者输出规则，选择、编辑具体回复，或者将生成结果公开推荐给不特定用户，其对具体内容的控制程度将明显增强，具体责任也需要相应调整。

1. 生成阶段：平台、搭建者和用户可能共同影响输出

实时回复通常经过如下过程：平台提供模型接入和运行能力，搭建者预先配置模型、提示词、知识库和工作流，终端用户再通过具体问题触发生成。

因此，很难仅凭“内容由平台服务器生成”就判断具体内容由谁提供。在平台仅提供通用接入和调度能力、搭建者掌握具体业务逻辑的情况下，平台的角色可能更接近SaaS型技术服务提供者。但如果平台对具体生成逻辑具有实质控制，则不能仅以技术服务为由排除其他责任评价。此时，产品设计的以下因素会影响结论：

• 平台是否只提供通用框架，还是直接设置关键生成规则；

• 搭建者是否能够自主选择模型和知识库；

• 终端用户的输入对结果是否具有实质影响；

• 输出是否经过平台或者搭建者的进一步筛选、编辑或者组合。

2. 交付不当然形成传播

如果生成结果只发送到某一用户的独立会话空间，其他用户无法访问，该交付方式与向不特定多数公开展示存在区别：在著作权场景中，一对一发送通常较难直接等同于信息网络传播行为，但是否涉及复制权或者其他权利，仍需结合内容形成、固定和发送过程判断；在人格权、商誉、虚假信息或者消费者权益场景中，即使内容只向特定用户发送，也不当然排除侵权可能，只是传播范围、损害程度和可采取措施可能有所不同。

在行为主体方面，如果搭建者设置了会话逻辑，并决定在何种条件下调用何种模型和知识库，平台只是按照预设规则自动完成传输，那么平台可能更接近自动接入或者自动传输服务提供者。具体可以考察：

• 平台是否选择、修改或者干预单条回复；

• 平台经营的主要是通用搭建和运行能力，还是直接以某类具体内容或者特定输出效果作为业务卖点；

• 平台是否只提供基础承载和传输能力，而不对各智能体的具体业务逻辑和会话内容进行逐条审查；

• 平台的默认配置是否已经实质决定相关内容。

在前述条件具备的情况下，从复制和定向交付层面看，搭建者是决定是否以及如何向终端用户发送内容的一方，实质上实施了复制、发送行为；平台则按照搭建者预设的逻辑，在技术层面执行发送指令。反之，如果平台选择、修改或者推荐具体回复，或者直接控制智能体的生成和发送逻辑，则需要重新判断其是否仍然只是自动传输服务提供者。

3. 平台注意义务应与具体风险和可采取措施相匹配

在一对一会话中，要求平台对全部用户的所有回复进行事前审查，可能面临技术成本、准确性、个人信息保护和数据安全等多方面问题。因此，在平台不选择、不编辑具体内容的前提下，通常不宜笼统要求其对所有会话承担全面主动审查义务。但平台也不能因此排除一切处理义务。《民法典》第1195条要求网络服务提供者根据侵权初步证据和服务类型采取必要措施；第1197条则进一步规定平台知道或者应当知道侵权而未采取必要措施时的责任。

由此，对于实时生成内容的必要措施未必只能理解为删除某一条已经生成的回复。根据通知的具体程度和平台的技术能力，还可能包括：

• 暂停或者限制被具体指向的智能体；

• 停止调用特定知识库、模板或者外部工具；

• 调整明显具有侵权导向的默认配置；

• 对重复出现的高风险输出进行针对性限制；

• 保存必要记录并将通知转送给可识别的搭建者。

是否需要采取上述措施，以及采取到何种程度，应结合侵权类型和明显程度、通知的准确性、平台对智能体的控制能力、措施的技术可行性及其对其他用户权益的影响综合判断。

4. “无法查看会话”影响措施范围，但未必排除其他义务

如果平台在技术上或者合规上无法合法查看、定位具体会话内容，是否就可以不处理权利人的通知？答案并不是简单的“可以”或者“不可以”。“无权查看”影响的是必要措施等内容与范围，而不是平台是否需要采取措施。

一方面，平台通常确实不具备、也不应当具备对私人会话内容进行全面检索和分析的权限，否则可能与个人信息保护和数据安全要求发生冲突。另一方面，在合理、合规的前提下，平台仍可以保留有限的介入能力，例如对权利人已经充分举证、平台自身也能够识别的高风险智能体或模板采取针对性措施，或者在系统层面限制明显以侵权内容为主要卖点的智能体。

因此，更合理的责任边界是：不要求平台对所有智能体的历史会话内容进行“一刀切”的全面屏蔽和删除；但在不突破数据保护和技术可行性边界的前提下，平台仍应对被具体指向的高风险智能体或者功能模块采取相称的干预措施。

转载声明：好文共赏，如需转载，请直接在公众号后台或下方留言区留言获取授权。 如需引用文中观点、数据或评述，亦请提前联系我们取得授权。请勿随意摘编、节选或改编本文内容。

封面图源：杜飞辰·问题少年