AI 产品用户协议：十二个条款、六处失效与上线前核对清单

用户协议在多数 AI 公司里的位置是尴尬的：产品上线前一周由法务从模板改出，挂在注册页底部，之后只在监管问询或用户投诉时才被想起。但在一款生成式 AI 产品中，这份文件同时承担三项功能：界定服务规则的边界、分配输出不可预期所带来的责任、落地监管对服务提供者的合同要求。《生成式人工智能服务管理暂行办法》第九条要求提供者与注册其服务的使用者签订服务协议，明确双方权利义务。这一条把用户协议从"可选项"变成了监管要件。

写得全，不等于写得有效。实务中真正让条款落空的，通常不是缺条，而是格式条款的提示说明义务未履行、同意机制未落地，以及条款与产品的实际形态对不上。以下先讲性质与差别，再逐条拆解，最后给出失效清单与核对表。

一、先定性质：用户协议承担的三重功能

第一重是服务规则。服务提供什么、不提供什么、何时可以变更、何种行为导致封号，这些内容如果不写进协议，产品侧的运营决定就缺少合同依据。封号争议中企业最常败诉的地方，恰恰是协议里只有一句"本公司有权终止服务"，没有约定终止的触发条件与程序。

第二重是责任分配。生成式 AI 的输出无法在缔约时预先确定，输出可能不准确、可能侵犯第三方权利、可能被用户用于违法用途。这些风险如何在平台与用户之间分配，只能靠协议完成。法律不会替企业分配，只会审查分配是否显失公平。

第三重是监管义务的落地。除前述第九条的服务协议要求外，《暂行办法》第十条对训练数据处理提出要求，第十二条要求对生成内容进行标识；《人工智能生成合成内容标识办法》自 2025 年 9 月 1 日施行后，标识义务进一步具体化。这些义务有一部分只能通过协议条款向用户传导，例如要求用户在传播生成内容时保留标识、不得删除或篡改标识。

三重功能决定了协议不能只由法务单独完成。产品、运营、技术、客服都需要在条款形成阶段介入，否则写出来的规则与产品实际运行方式是两套逻辑。

二、AI 产品与传统 SaaS 的四个差别

差别决定写法。传统 SaaS 的条款模板直接套用，往往在这四处失准。

其一，输出不可预先确定。SaaS 承诺的是功能可用，AI 产品承诺的是能力可用，而能力输出的正确性无法保证。协议不能承诺"输出准确、完整、可靠"，但也不能只写一句"不作任何保证"——后者在格式条款审查中容易被认定为排除主要权利。

其二，模型会变。版本迭代、模型切换、能力下线都属于常态。协议需要保留变更权，但变更权必须配上通知方式与生效时间，否则用户对"我买的东西明天可能不一样"缺少预期。

其三，输入可能是他人的个人信息或商业秘密。用户把客户名单、合同文本、员工信息粘进对话框，平台由此成为这些信息的处理者。协议必须要求用户保证其输入具备合法基础，同时明确平台对这些输入的处理规则。

其四，输出可能侵犯第三方权利。模型训练数据来源复杂，输出与既有作品相似的情形无法完全排除。协议需要约定用户在使用输出前的自查义务，以及发生第三方主张时的通知与配合机制。

三、十二个必须写清的条款

1. 服务描述与模型变更权。 写明服务的基本形态、能力范围与不适用场景，再约定变更权。变更条款应区分两类：不影响核心功能的优化，可即时生效；导致能力实质性下降或计费方式变化的，应提前通知并给予用户终止权。把两类混为一条"有权随时调整服务"，等于把变更权写成了一张空白授权。

2. 账号、实名与年龄。 区分个人用户与企业用户，分别约定注册信息、账号归属与管理员权限。企业版应明确账号由企业管理员分配、员工离职后的回收方式。年龄条款不能只写"未成年人须经监护人同意"，还需与产品是否提供未成年人模式、是否做年龄识别相呼应；未做识别却写了同意条款，条款本身不产生免责效果。

3. 生成内容的权属与许可。 这是最影响商业成交的一条。对 C 端产品，约定输出内容的权利归用户，平台为提供服务与改进模型取得一项有限许可，并明确许可范围、期限与是否可转授权。对企业客户，多数情况下需要约定输出权利归企业，且平台不得将企业输入用于训练。把权属一律写成"归平台所有"，会直接导致商用客户在采购审查阶段出局。

4. 用户输入的权利担保。 要求用户保证其输入不侵犯他人知识产权、不含未经授权的个人信息、不违反保密义务。这一条的作用不在于让平台免责，而在于为平台在收到第三方主张时提供抗辩基础与追偿依据。

5. 可接受使用政策。 违法内容生成、越狱提示、批量抓取、转售 API、利用输出实施欺诈，这些禁止性行为条款写不进正文，应单独作为附件。附件的好处是可以独立更新，且便于在封号争议中举证平台已明确规则。

6. 付费、计费与退款。 按 token 计费的产品，需写明计量口径、额度有效期、超额处理与价格调整方式。退款条款应区分未使用额度与已消耗服务，避免一句"概不退款"被认定为排除消费者主要权利。

7. 可用性与服务等级。 C 端可采"尽力提供"的表述，但应说明计划内维护与不可抗力的处理；企业版则需约定可用性指标、故障响应时限与未达标的补偿方式。把企业版的 SLA 写成"尽力而为"，在采购评审中通常不被接受。

8. 责任限制与赔偿上限。 可以约定间接损失不负赔偿责任，也可以设置赔偿上限，但不得排除人身损害责任，不得排除因故意或重大过失造成的损失。责任限制条款必须以合理方式提示，未履行提示说明义务的，条款可能不成为合同内容。

9. 知识产权与第三方权利。 明确平台对产品、界面、文档享有权利，用户不得反向工程、不得去除权利标识。同时约定输出涉及第三方权利时的处理流程：用户通知、平台核查、暂停使用与后续安排。

10. 数据与隐私的交叉引用。 用户协议不重复隐私政策的全部内容，但必须完成三件事：指明隐私政策是协议的组成部分、说明两者冲突时的适用顺序、提示用户输入中若含他人个人信息应由用户自行取得授权。训练数据使用条款不应只藏在隐私政策里，涉及将用户输入用于模型改进的，应单独告知并取得同意。

11. 终止、封号与数据导出。 约定终止的触发情形、通知方式、申诉渠道与数据导出窗口。封号属于对用户权利影响较大的措施，应区分临时限制与永久终止，并保留人工复核环节。缺少程序的终止条款，在诉讼中很难被认定为已履行合同义务。

12. 争议解决、法律适用与通知送达。 约定适用中华人民共和国法律、管辖法院或仲裁机构，并写明通知送达方式（注册邮箱、站内信、公告）。面向消费者的格式管辖条款若排除消费者选择其他管辖的权利，存在被认定无效的风险。

四、六处最常见的失效

这六处的共同点是：条款在文本上存在，在法律上不成立。判断标准不是"有没有写"，而是"有没有履行配套程序"——提示、告知、单独同意、可撤回，这四项程序缺一项，条款的效力就打折扣。

五、文档结构：正文、附件与变更记录

成熟的用户协议通常不是一份文件，而是一组文件。

正文约定双方的基本权利义务；附件承载可独立更新的规则，包括可接受使用政策、服务等级说明、数据处理协议；变更记录保留历次版本、生效日期与变更要点。三部分的价值在于举证：发生争议时，能够证明某一时点的规则内容、用户当时所见版本，以及平台是否履行了通知义务。

变更记录尤其容易被忽略。监管问询与诉讼中，“用户注册时同意的是哪一版"是常见问题，没有版本留存的，企业往往只能以现有版本作答，而这恰好是最不利的答法。

六、上线前核对清单

清单中的第 7 项与第 8 项最常被跳过。前者因为提示说明义务需要改动注册页交互，后者因为单独同意需要产品侧增加一个勾选。两项都属于"法务提要求、产品不改"的典型断点，而它们恰恰是条款能否生效的关键。

七、结语

用户协议的质量，最终不取决于条款写得多细，而取决于三件事是否做到：条款与产品形态一致、格式条款的提示说明程序到位、同意与撤回机制真实可用。做到这三点，协议才从一份免责文本变成一套可执行的规则；做不到，写得再长也只是在争议发生时增加了一页需要解释的材料。

站内相关梳理：AI 企业核心合同清单、AI 企业数据合规的五大风险点、未成年人用网新规对 AI 服务的两类要求、大型个人信息处理者的新增义务，以及数据合规与商业合同服务页。

最后更新：2026 年 6 月 11 日。