Contract Review

Contract Review

面向企业法务、采购、销售、运营、HR 与业务负责人场景的合同审核技能。

目标不是只做“找几个风险点”的泛泛点评，而是形成一套可复核的审查链路：

• 先定审查目标和适用标准
• 再拆条款和缺失项
• 再核对法律法规与公司规则
• 再形成风险分类、修改建议与签署意见

先读什么

• 用户未明确法域，且合同和沟通语言明显是中文商事场景时，先读 references/prc-defaults.md。
• 先读 references/source-hierarchy.md，明确法源、监管、公司制度和市场惯例的层级。
• 再按合同类型读取 references/clause-checklists.md，补齐常见条款检查点。
• 若为 NDA，追加读取 references/prc-nda-redlines.md。
• 若为采购合同，追加读取 references/prc-procurement-redlines.md。
• 若为 SaaS 协议，追加读取 references/prc-saas-redlines.md。
• 若为服务协议，追加读取 references/prc-service-redlines.md。
• 需要生成红线、替代条款或谈判口径时，读取 references/standard-redlines.md。
• 需要直接产出可粘贴条款时，读取 references/clause-templates.md。
• 用户没有公司规则但希望建立内部红线时，读取 references/company-redline-template.md。
• 进入风险识别时读取 references/risk-taxonomy.md。
• 出最终报告前必须读取 references/report-template.md。

适用输入

• 合同全文或节选，直接粘贴到对话
• 本地文件路径，优先 md、txt、html
• 已提取文本的 docx / pdf
• 对比场景：用户给出“对方版本”和“我方模板/红线”
• 审查标准：公司制度、审批矩阵、交易政策、法务 playbook、标准模板

如果用户只给图片扫描件、不可复制 PDF 或零散截图：

• 先尽量提取结构化文本
• 提取失败时，明确说明无法可靠逐条审查，并要求可复制文本或关键条款摘录

默认设置

• 默认输出语言：zh-CN
• 默认模式：standard
• 默认风险口径：balanced
• 默认法域：中国大陆
• 默认输出目录：contract-reviews/{slug}-{timestamp}/
• 默认签署建议：只有在证据和关键条款足够时才给出；否则输出“需补充信息后判断”
• 默认审查标准顺序：

1. 强制性法律法规与监管要求 2. 用户提供的公司制度、审批规则、合同模板、红线清单 3. 行业惯例与交易常识 4. 本技能内置的通用检查清单

如果用户没有提供公司制度或模板：

• 继续完成通用审查
• 但必须明确标记“未按贵司内部制度校验”
• 可以使用内置标准红线作为通用企业立场起点
• 不得虚构内部政策、审批权限或红线

如果用户未说明法域，且合同属于中文企业交易场景：

• 默认按中国大陆商事合同口径审查
• 涉及数据、个人信息、跨境传输、商业秘密、劳动或顾问安排时，优先读取 references/prc-defaults.md
• 最终报告里明确标记“本次默认以中国大陆法语境审查；如合同约定境外法或境外争议解决，需进一步复核”

审查模式

自动判断规则：

• 用户说“快速看一下”“先扫雷”“不用太细”时，用 quick
• 用户提到“马上签”“请给能不能签的结论”“按公司规定过一遍”时，至少用 standard
• 涉及数据出境、知识产权独占、排他、巨额违约责任、监管牌照、劳动用工、高金额采购、长期 SaaS 或重大合作时，升级到 signing-gate

五个 Agent 的职责

不要真的把它们写成互相脱节的五份答案，而是按这个顺序串行工作并把中间产物落盘。

1. Planner Agent

负责定义任务边界和审查口径。

至少确认：

• 合同类型
• 审查目标：合规、商业、采购、销售、交付、数据、IP、用工、签署把关
• 交易角色：我方 / 对方 / 中立
• 是否有我方模板、公司政策、审批矩阵、红线
• 是否要求出修改建议、替代条款、签署结论
• 时效要求与版本信息

输出到 00-brief.md。

2. Clause Agent

负责把合同拆成“可审查单元”，不要直接在大段正文里混着点评。

任务：

• 建立条款目录和 clause id
• 识别关键定义、权利义务、金额、期限、触发条件、例外、责任分配
• 标记缺失条款、冲突条款、模糊表述和空白变量
• 必要时把无编号合同切成 C1、C2、C3 形式

输出到 01-document-map.md 和 02-clause-register.md。

3. Law Agent

负责核对“依据”而不是凭经验下结论。

任务：

• 识别适用法域、行业监管、数据合规、反商业贿赂、出口管制、劳动用工等问题
• 检索并记录法律法规、监管规则、司法解释、用户提供的公司制度
• 对每条依据写清：来源级别、标题、发布日期/生效日期、与你的审查结论的关系
• 区分：
• 违法/违规风险
• 违反公司制度或审批要求
• 市场惯例偏离

在中国大陆法默认场景下：

• 先读 references/prc-defaults.md
• 合同通用问题优先从《中华人民共和国民法典》合同编口径出发
• 涉及个人信息、数据处理、跨境传输时，优先核对 PIPL、DSL、现行网安法及国家网信办规则
• 涉及保密、竞业、技术资料、源码、客户名单时，额外注意商业秘密和反不正当竞争风险
• 涉及顾问、驻场、灵活用工时，额外注意被重定性为劳动关系或产生用工合规义务的风险

输出到 03-authority-log.md。

4. Risk Agent

负责把问题归类、定级、解释后果，并形成可执行的处理建议。

任务：

• 使用 references/risk-taxonomy.md 的分类与级别
• 合并重复问题，避免同一风险在多个条款里重复记账
• 判断是“必须修改”“可谈判”“可接受但需知悉”“信息不足”
• 对每个问题给出：
• 风险等级
• 风险类别
• 触发条款
• 依据
• 影响
• 建议动作

输出到 04-risk-register.md。

5. Report Agent

负责把审查结论变成业务能直接使用的交付物。

任务：

• 用 references/report-template.md 生成终稿
• 输出执行摘要、关键风险、建议红线、待确认问题、签署建议
• 如果用户需要，额外生成“给业务的非法律语言摘要”

输出到 05-redlines.md 和 06-review-report.md。

输出文件

为每次任务创建目录：contract-reviews/{slug}-{timestamp}/

• source.md：统一落盘的合同文本或摘录
• 00-brief.md：任务边界、合同类型、审查标准、版本信息
• 01-document-map.md：合同元数据、结构总览、缺失项初筛
• 02-clause-register.md：条款台账
• 03-authority-log.md：法律法规、监管规则、公司制度、模板比对依据
• 04-risk-register.md：风险台账
• 05-redlines.md：建议修改方案或替代条款
• 06-review-report.md：最终审查报告
• 07-open-questions.md：信息不足或需业务确认的问题；只有在需要时生成

如果用户只要聊天窗口里的答案，仍然默认保存 06-review-report.md，并在回复里给出路径。

工作流

Step 1: 建立审查任务，写入 00-brief.md

优先从当前对话中提取，不要为了默认项反复追问。至少写清：

• 合同名称与版本
• 合同类型
• 我方角色
• 目标法域或争议解决地
• 审查模式
• 是否有公司制度/模板/红线
• 是否要求替代条款
• 是否要求签署结论
• 当前资料缺口

如果用户没有说清合同类型，先根据条款内容推断为以下之一：

• nda
• service
• procurement
• saas
• license-ip
• employment-consulting
• data-processing
• other

Step 2: 落盘正文并建立文档地图

1. 将用户提供的正文统一写入 source.md 2. 提取：

• 合同名称
• 签约主体
• 定义条款
• 商业条款
• 责任条款
• 争议解决条款

3. 写 01-document-map.md 4. 没有条款编号时，为每个可审查单元分配 C1、C2 等标识 5. 生成 02-clause-register.md

02-clause-register.md 建议列：

Step 3: 依据检索与标准比对，写入 03-authority-log.md

执行原则：

• 先读 references/source-hierarchy.md
• 凡是和法律责任、合规义务、数据处理、牌照、劳动、知识产权归属、违约责任、争议解决直接相关的结论，都要给出处
• 时效敏感内容必须核对发布日期和生效日期
• 不能把“市场常见做法”写成“法律要求”
• 用户提供的公司制度、模板、审批权限表属于内部约束，必须单独标明

03-authority-log.md 建议列：

Step 4: 识别风险并写入 04-risk-register.md

执行顺序： 1. 逐条扫描 clause register 2. 用合同类型检查清单补查缺失项 3. 在中国大陆场景下，再读取对应合同类型的 PRC 专项红线文件 4. 将问题映射到风险分类 5. 评估严重性、发生概率、可修复性 6. 形成处理建议

04-risk-register.md 每个问题至少包含：

• risk_id
• severity
• category
• clause_id
• issue
• basis
• impact
• recommended_action
• fallback_position
• owner_question（如需业务补信息）

Step 5: 生成修改建议，写入 05-redlines.md

当用户要求“给修改建议”“给替代条款”“按我方立场改”时，必须生成。

写法要求：

• 先读 references/standard-redlines.md，确定优先级和 fallback 立场
• 若默认按中国大陆法语境审查，再叠加读取对应合同类型的 PRC 专项红线文件
• 需要具体替代表达时，再读 references/clause-templates.md
• 优先给“为什么要改”和“改成什么”
• 替代条款要尽量可直接粘贴到合同
• 不知道法域或交易背景时，不要编造高度具体的法言法语
• 如果只能给方向性建议，明确标记为“条款方向建议”而非可直接签署文本

Step 6: 生成审查报告，写入 06-review-report.md

必须使用 references/report-template.md。

报告里要清楚区分：

• 明确违法或违规风险
• 不符合公司制度或内部红线
• 对我方明显不利但可谈判的商业风险
• 信息不足，暂不能下结论的点

Step 7: 形成签署建议

签署建议只允许输出以下四类之一：

• 建议签署
• 修改后可签
• 暂不建议签署
• 需补充信息后判断

判定原则：

• 存在 Critical 且未覆盖的风险，通常为 暂不建议签署
• 存在重大资料缺口，输出 需补充信息后判断
• 主要问题是商业谈判项且有清晰 redline，可输出 修改后可签
• 只有轻微或可接受偏离时，才考虑 建议签署

审查结论的写法标准

每条结论尽量遵循这个顺序： 1. 先指出条款或缺失项 2. 再写风险是什么 3. 再写依据是什么 4. 再写会造成什么后果 5. 最后给修改建议或确认问题

避免这些问题：

• 只说“有风险”，不说风险具体在哪
• 只凭经验断言违法，不写依据
• 把内部偏好说成法律底线
• 给出脱离交易背景的极端 redline
• 在信息不足时给出过强结论

高风险事项的默认加严规则

遇到下列事项，默认提升一级审查强度：

• 无上限赔偿、间接损失、利润损失、惩罚性责任
• 永久排他、默认独占、过宽竞业限制
• 知识产权全部转让、成果归属不清、背景 IP 被搭进去
• 大规模个人信息处理、跨境传输、审计权过宽
• 单方解除、自动续约、单方变价、验收标准缺失
• 回款条件严重后置、预付款无保障、抵销规则不对等
• 管辖、仲裁地、适用法对我方极不利
• 代表与保证过宽，超出我方可控范围

证据与边界

• 这是合同审查工作流，不是替代持牌律师出具正式法律意见
• 没有经过核源的结论，不要包装成确定性判断
• 没有看到完整合同全文时，明确说明结论仅基于已提供部分
• 如果公司制度与法律冲突，优先指出法律冲突，再单列内部流程建议

Clause Checklists

先用“通用检查项”扫一遍，再按合同类型补专项检查。

通用检查项

无论什么合同，至少检查以下事项：

1. 主体与授权

• 签约主体是否准确
• 关联公司、分支机构、代理签署是否写清
• 是否存在超授权承诺

2. 标的与范围

• 服务、货物、许可、成果范围是否明确
• 交付边界、例外、前提条件是否完整

3. 价格与付款

• 计费口径、税费承担、开票条件、付款节点是否清楚
• 是否存在“先履约后无限期付款”

4. 期限与终止

• 生效条件、期限、自动续约、提前终止是否合理
• 终止后的费用、数据、资料返还是否写清

5. 验收与交付

• 验收标准、时限、默认验收机制是否明确
• 交付失败的补救机制是否充分

6. 违约责任

• 违约金、赔偿范围、上限、排除责任是否平衡
• 是否包含间接损失、利润损失、惩罚性表述

7. 陈述保证

• 是否超出一方可控制范围
• 是否形成持续、无限制的责任

8. 保密与数据

• 保密信息定义、例外、期限、返还销毁是否清楚
• 涉及个人信息、数据出境、审计、系统接入时是否有额外义务

9. 知识产权

• 背景 IP、交付成果、衍生成果、改进成果归属是否明确
• 是否误把原有能力一并转让

10. 转包、转让、变更

• 是否允许分包、转让、控制权变更
• 变更流程是否受控

11. 不可抗力与免责

• 是否被滥用为一般违约免责
• 是否设置通知与减损义务

12. 通知、适用法与争议解决

• 通知机制是否有效
• 管辖、仲裁地、适用法是否对我方明显不利

NDA / 保密协议

重点检查：

• 保密信息定义是否过宽或过窄
• 例外情形是否完整：公开、已知、独立开发、合法第三方取得
• 保密义务期限是否合理
• 允许披露对象是否包括员工、顾问、关联方
• 返还/销毁义务是否可执行
• 残余记忆、禁反向工程、禁招揽条款是否过重
• 单方 injunctive relief 或单方免责是否失衡

Service / 服务协议

重点检查：

• 服务范围、SLA、里程碑、验收是否可衡量
• 客户配合义务是否写明
• 延误责任是否与依赖条件挂钩
• 人员更换、驻场、成果物、维保范围是否清楚
• 变更单机制是否存在

Procurement / 采购合同

重点检查：

• 规格、数量、交货地、运输、安装调试是否明确
• 验收、质保、返修、换货、退货机制是否完整
• 发票、付款条件、质保金、履约保证是否合理
• 供应链合规、环保、安全生产、进场义务是否覆盖

SaaS / 软件服务协议

重点检查：

• 服务可用性、停机通知、数据导出与迁移机制
• 客户数据使用边界、日志保留、审计配合
• 信息安全事件通报时限
• 订阅期限、自动续费、涨价权、用户数或用量定义
• 第三方组件、开源合规、服务变更权

License / IP 许可

重点检查：

• 许可类型：独占、排他、非独占
• 地域、领域、期限、再许可权
• 改进成果、衍生作品、反馈、商标使用权
• 侵权担保与侵权索赔责任

Employment / Consulting

重点检查：

• 服务关系性质是否可能被重定性
• 工作成果、发明、数据、保密和竞业安排
• 费用报销、考核、工时、交付标准
• 是否形成事实劳动关系或社保风险

Data Processing

重点检查：

• 数据角色：控制者、处理者、受托方
• 处理目的、范围、期限、地点
• 跨境传输、分处理者、审计、删除和返还机制
• 安全事件通知、协助义务、最小必要原则

缺失条款判断

以下情况即使正文没有显著问题，也要标为“缺失项”：

• 没有付款条件
• 没有验收标准
• 没有终止后处理
• 没有责任上限或风险分配机制
• 涉及数据但没有数据安全/保密安排
• 涉及成果输出但没有 IP 归属安排
• 涉及长期合作但没有变更机制

Clause Templates

以下模板用于生成 05-redlines.md 中的替代条款。它们是通用商业模板，不应被包装为特定法域的最终法律文本。

使用原则：

• 先匹配交易类型，再决定是否可直接引用
• 不确定法域、监管或业务模式时，优先给方向性修改，再给模板
• 输出时尽量保留可替换占位符，例如 [X]、[服务说明]、[天数]

1. 责任上限

除因一方故意不当行为、重大过失、保密义务违反、知识产权侵权或法律明确不得限制的责任外，任一方在本合同项下承担的累计赔偿责任总额不超过对方在导致该等责任事项发生前十二（12）个月内已支付或应支付的合同总价。

2. 间接损失排除

任何一方均不对另一方承担任何间接性、附带性、特殊性、惩罚性或后果性损失，包括但不限于利润损失、收入损失、商誉损失、数据损失或替代采购成本，但法律另有强制规定或本合同另有明确约定的除外。

3. 验收机制

甲方应在收到乙方交付成果后 [10] 个工作日内完成验收并书面反馈。若甲方在前述期限内未提出具体且合理的不符合项，则相应交付成果视为验收通过。乙方应在合理期限内对不符合项进行整改并重新提交验收。

4. 付款节点

甲方应在相应发票及付款申请资料齐备且对应成果验收通过后 [30/45/60] 日内支付相应款项。任何付款争议不得影响对无争议部分款项的及时支付。

5. 自动续约

本合同期限届满前任一方如无续约意向，应至少提前 [30] 日书面通知对方；如双方均未发出终止通知，本合同可按原条件续展一个连续期间。续展期间的价格或服务范围变更应经双方另行书面确认。

6. 单方便利解除

任一方如因经营安排需要提前解除本合同，应至少提前 [30] 日书面通知对方，并就对方截至解除生效日已实际完成的工作、已发生且不可撤销的合理成本及双方已确认的应付款项进行结算。

7. 背景 IP 保留

各方在本合同签署前已拥有或独立开发形成的技术、软件、工具、文档、数据、方法、模型、流程、商标及其他知识产权或相关权益，均归原权利人所有。本合同项下任何交付、配合、接口、反馈或建议，均不视为对前述背景知识产权的转让。

8. 项目成果许可

在甲方按约足额支付相关费用后，乙方授予甲方一项非独占、不可转让、不可再许可、在本合同约定目的范围内使用项目成果的权利；除双方另有书面约定外，乙方保留其通用工具、底层技术、预先存在素材及通用 know-how 的全部权利。

9. 数据用途限制

乙方仅得在履行本合同所必需的范围内收集、访问、使用、存储和处理甲方数据，不得将甲方数据用于画像、建模、训练、营销、转售、共享或任何与履约无关的目的，除非取得甲方事先书面同意或法律法规另有明确要求。

10. 数据事件通知

如发生任何导致或可能导致甲方数据被未经授权访问、披露、丢失、损坏、篡改或不可用的安全事件，乙方应在知悉后 [24/48] 小时内通知甲方，并及时提供事件性质、影响范围、已采取措施及后续整改计划。

11. 审计权限制

甲方对乙方的审计仅限于与本合同履行直接相关的资料和流程，且应至少提前 [10] 个工作日书面通知。审计原则上每个合同年度不超过 [1] 次，审计时间、范围和方式应合理，不得无故干扰乙方正常经营；审计中知悉的信息应受严格保密义务约束。

12. 保密条款例外

保密义务不适用于下列信息：一方能够证明其在披露时已为公众所知的信息；在披露前已合法持有的信息；在未使用对方保密信息的情况下独立开发获得的信息；或从有权披露的第三方合法取得的信息。

13. 转让限制

未经另一方事先书面同意，任一方不得转让本合同或其在本合同项下的主要权利义务，但因合并、分立、重组或整体业务转让而向其关联方或承继主体转让且不实质影响另一方权益的除外；转让方应确保受让方继续履行本合同义务。

14. 终止后协助

本合同终止或解除后，乙方应在 [30] 日内按甲方要求返还或删除甲方数据及资料，并在合理范围内提供数据导出、交接说明和过渡协助；如该等协助超出原合同服务范围，双方可另行协商合理费用。

15. 争议解决折中版本

因本合同引起或与本合同有关的任何争议，双方应先友好协商解决；协商不成的，任一方可向 [被告住所地/合同履行地/约定仲裁机构] 提起诉讼或仲裁。争议期间，除争议事项外，双方仍应继续履行未受影响的其他条款。

输出注意

• 如果模板被选用，要同时说明它解决了哪个风险
• 如果模板存在明显法域依赖，例如数据跨境、劳动关系、反贿赂，必须标注“需结合当地法进一步定稿”
• 如果用户要求“我方强势版本”和“可让步版本”，可在同一条下提供 主张版 与 fallback 版

Company Redline Template

这个模板用于把“标准红线”升级成你们自己的公司版本。建议用户把内部规则整理成类似结构，再让 contract-review 读取。

1. 公司基础信息

# 公司合同红线模板

## 适用范围
- 适用主体：
- 适用业务线：
- 生效日期：
- 版本号：
- 维护部门：

2. 审批分级

## 审批矩阵
| 情形 | 审批要求 |
|------|----------|
| 金额超过 [X] | [法务负责人/财务/总经理] |
| 无上限责任 | [法务负责人 + 管理层] |
| 涉及数据出境 | [法务 + 安全/隐私负责人] |
| 涉及独占或排他 | [业务负责人 + 法务负责人] |
| 偏离标准模板核心条款 | [法务负责人] |

3. 条款红线清单

## 条款红线
| 条款主题 | 默认立场 | 不可接受情形 | 可接受 fallback | 额外审批 |
|----------|----------|--------------|-----------------|----------|
| 责任上限 | 红线 | 无上限赔偿 | 一般责任 capped，特定 carve-out 单列 | 是 |
| 付款条款 | 重点争取 | 验收后超 [60] 天付款 | 验收后 [45/60] 天内付款 | 否 |
| 数据使用 | 红线 | 任意分析、训练、共享 | 限履约必要范围 | 是 |
| IP 归属 | 红线 | 背景 IP 被转让 | 仅授予项目目的使用许可 | 是 |
| 自动续约 | 重点争取 | 无退出窗口 | 提前 [30] 天通知可退出 | 否 |

4. 合同类型专项规则

## NDA
- 禁招揽期限不得超过 [12] 个月
- 残余记忆条款默认不接受 / 仅限狭义版本

## SaaS
- 必须有数据导出机制
- 供应商不得未经同意使用客户数据训练模型

## 采购
- 验收后付款不得超过 [60] 天
- 必须有现场安全与数据安全义务

5. 报告结论规则

## 签署建议映射
- 出现任一 Critical 红线未解决：暂不建议签署
- 存在 High 风险但有明确 redline：修改后可签
- 仅有 Medium/Low 且业务确认接受：建议签署
- 资料不完整或关键事实缺失：需补充信息后判断

使用建议

• 没有现成制度时，可以先复制这里的结构，再填入公司真实口径
• 有内部模板、审批矩阵、法务手册时，优先用真实文件替换这里的占位内容
• 不要把这个模板中的占位数字直接当成最终公司政策

PRC Defaults

本文件用于“未明确法域、但明显属于中国大陆中文商事合同”的默认审查口径。

不要把这里当成穷尽式法律意见。它的作用是：

• 帮模型先选对中国大陆法语境
• 让 redline 更贴近本土交易实践
• 在数据、保密、用工等高风险处更保守

按合同类型继续读取

确定合同类型后，继续加载对应专项文件：

• NDA：见 prc-nda-redlines.md
• 采购合同：见 prc-procurement-redlines.md
• SaaS 协议：见 prc-saas-redlines.md
• 服务协议：见 prc-service-redlines.md

适用触发

出现以下任一情形时，优先按本文件审查：

• 合同和对话为中文
• 签约主体、履约地、争议解决地明显在中国大陆
• 用户未指定适用法，但希望按“公司法务/企业常规口径”审核
• 涉及中国大陆员工、客户、供应商、数据处理或境内交付

默认法源顺序

1. 民商事合同基础规则

优先以《中华人民共和国民法典》合同编为基础。

重点关注：

• 合同订立、格式条款、效力、履行、变更、解除、违约责任
• 免责条款边界
• 书面形式与电子文本效力
• 附随义务，如通知、协助、保密

审查提示：

• 不要轻易把商业不利条款直接写成“无效”
• 但对格式条款提示、免责条款、显失平衡安排要更敏感

2. 个人信息与数据

涉及个人信息、客户数据、员工数据、日志、画像、训练、境外访问时，优先核对：

• 《中华人民共和国个人信息保护法》
• 《中华人民共和国数据安全法》
• 《中华人民共和国网络安全法》现行有效版本
• 国家网信办现行数据出境规则

默认保守口径：

• “为履约所必需”不是无限授权
• 数据用途必须限定
• 能被境外访问处理的数据，也可能构成数据跨境场景
• 合同里若写“供应商可出于服务改进、产品优化、模型训练等目的使用客户数据”，默认至少是 High

3. 商业秘密与保密

涉及源码、技术文档、客户清单、价格、投标信息、经营信息、模型参数等时，优先按商业秘密保护和反不正当竞争风险处理。

默认保守口径：

• 残余记忆条款要谨慎
• “可向任何关联方披露”默认过宽
• 返还/删除/销毁义务要有操作边界，但不能空缺

4. 用工与顾问

涉及劳动、顾问、驻场、长期个人服务时，额外关注：

• 是否可能被重定性为劳动关系
• 工作成果归属和发明约定
• 竞业限制、保密、个税与社保风险

默认保守口径：

• 如果个人顾问长期、持续、受强管理、按月固定报酬、类似员工管理，至少提示存在用工重定性风险

中国大陆法语境下的默认加严点

A. 免责条款

对这类条款默认更严：

• 造成人身损害的免责
• 因故意或重大过失造成对方财产损失的免责

写法上：

• 不要笼统说“免责条款无效”
• 应写成“该免责安排可能超出中国大陆法允许的边界，需要收缩或重写”

B. 格式条款

如果合同明显由一方预先拟定，且存在：

• 免除己方责任
• 加重对方责任
• 排除对方主要权利

则至少提示格式条款风险，并建议：

• 对关键条款做醒目标识
• 保留明确协商痕迹
• 删除过度失衡表述

C. 数据跨境

如果合同出现以下任一情况，默认升级审查强度：

• 境外主体远程访问境内数据
• 客户数据上传境外服务器
• 员工、人力资源、客服、CRM 数据跨境共享
• 合同直接写“可将数据传输至全球关联公司”

默认输出要求：

• 明确标记是否涉及“可能的数据跨境”
• 不要只写技术安全问题，要同时写合规路径问题

D. 发票、税费与付款

在中国大陆交易实践里，付款条款应尽量写清：

• 含税/不含税
• 发票类型
• 开票条件
• 付款时间与验收的关系

默认风险：

• 只写“收到发票后付款”但不写验收或资料条件，容易引发争议
• 只写“满意后付款”，默认过于主观

E. 管辖与送达

默认更偏好：

• 明确法院或仲裁机构
• 明确送达地址与电子送达方式
• 避免只有英文送达机制、但主体在中国大陆且执行路径不清

建议的本土 redline 口径

数据条款

• 原则上不接受“履约 + 服务改进 + 训练 + 商业分析”打包授权
• 原则上要求把用途拆开，并把训练、共享、出境改成需单独书面同意

保密条款

• 中国大陆商业合作里，保密定义可以广，但例外必须完整
• 对“永久保密”要拆成：核心商业秘密可长期，普通商业信息设合理期限

责任条款

• 一般责任最好设 cap
• carve-out 要具体，不宜写成“任何违反合同的行为均不受限制”

用工/顾问条款

• 不要只从 IP 角度写顾问合同
• 必须顺手检查管理方式和报酬结构是否会引出劳动关系争议

报告中的默认表述

在中国大陆默认场景下，优先使用这种表达：

• “按中国大陆法的一般合同审查口径，……”
• “在中国大陆个人信息与数据合规框架下，……”
• “若合同项下数据可被境外主体访问或处理，需进一步评估是否触发数据跨境合规要求。”
• “该安排在中国大陆商事实践中通常会被视为对我方明显不利，建议收窄。”

时间边界

本文件按截至 2026-03-17 可见的中国大陆现行规则整理。

对于时效敏感事项，至少重新核对：

• 数据出境规则
• 网络安全与数据合规监管规则
• 劳动与社保的地方性要求
• 行业监管特别规定

核对清单

在引用本文件给出结论前，至少确认：

• 是否真的是中国大陆场景
• 是否存在约定适用境外法或境外争议解决
• 是否涉及个人信息、重要数据、跨境访问
• 是否属于劳动/顾问/派驻等容易变形的关系
• 是否有用户提供的公司制度会覆盖默认口径

PRC NDA Redlines

适用于中国大陆语境下的：

• 单向保密协议
• 双向保密协议
• 商务接洽前的保密承诺
• 含保密附件的合作协议

主要依据方向：

• 《中华人民共和国民法典》合同编
• 《中华人民共和国反不正当竞争法》关于商业秘密和诚信竞争的规则
• 交易实践中的商业秘密保护边界

审查目标

NDA 的重点不是把保密义务写得越重越好，而是：

• 保密对象清楚
• 保密边界可执行
• 例外完整
• 泄露后的救济合理
• 不借 NDA 偷渡竞业、排他、知识产权转让或事实上的长期限制

红线清单

1. 保密信息定义

• 默认立场：重点争取
• 红线情形：
• 定义无限宽泛，几乎覆盖一切接触信息，但没有例外
• 把“口头交流”“未来信息”“观察到的一切情况”全部纳入，但无确认机制
• 建议方向：
• 允许书面、电子、口头信息纳入，但口头信息应在合理期限内补充书面确认
• 保密信息应与商务接洽、尽调、合作评估目的相关
• fallback：
• 即使定义较宽，也必须补齐例外和披露范围控制

2. 保密例外

• 默认立场：红线
• 红线情形：
• 未列公开、已知、独立开发、合法第三方取得等例外
• 建议方向：
• 例外至少覆盖以上四类
• fallback：
• 如对方坚持收窄例外，至少保留“已知”“独立开发”“合法取得”

3. 披露对象

• 默认立场：重点争取
• 红线情形：
• 只允许极少数自然人知悉，导致无法内部评估
• 允许无限制向任何关联方披露
• 建议方向：
• 仅允许向有知悉必要的员工、顾问、审计、律师、关联方披露，并要求其承担不低于本协议的保密义务
• fallback：
• 对关联方披露加“履约/评估必要 + 保密约束 + 责任回溯”

4. 保密期限

• 默认立场：重点争取
• 红线情形：
• 全部信息永久保密
• 建议方向：
• 核心商业秘密可长期保护
• 普通商务信息设置合理期限，例如 2-5 年
• fallback：
• 即使期限较长，也应区分商业秘密与一般信息

5. 使用目的限制

• 默认立场：红线
• 红线情形：
• 对方可将信息用于产品改进、训练模型、竞争分析、客户挖掘等与接洽无关用途
• 建议方向：
• 明确仅用于评估、谈判、履行拟议合作
• fallback：
• 如要保留内部分析用途，必须去标识、限目的、不得对外共享

6. 残余记忆条款

• 默认立场：红线
• 红线情形：
• 接收方可基于员工记忆自由使用、开发、商业化
• 建议方向：
• 原则上删除
• 若必须保留，应仅限“非刻意记忆、未形成复制、未构成商业秘密挪用”的狭义版本
• fallback：
• 保留时不得突破商业秘密保护和用途限制

7. 禁招揽 / 禁挖角

• 默认立场：重点争取
• 红线情形：
• 对象过宽，覆盖所有员工、顾问、客户、供应商
• 期限过长，明显超出交易需要
• 建议方向：
• 限缩为双方直接接触并参与项目的核心人员
• 期限控制在合理范围，如 6-12 个月
• fallback：
• 允许通过公开招聘、猎头渠道的非定向接触

8. IP 偷渡

• 默认立场：红线
• 红线情形：
• NDA 中夹带“反馈归对方所有”“接洽中形成的一切想法均归对方”
• 建议方向：
• NDA 只处理保密，不处理成果转让；如需另签条款，应单列
• fallback：
• 最多允许非独占、限目的使用反馈，不得转移背景 IP

9. 救济与责任

• 默认立场：重点争取
• 红线情形：
• 约定单方可直接申请禁令、冻结、惩罚性违约金，且责任明显失衡
• 建议方向：
• 保留守约方寻求禁令或紧急救济的权利，但表述尽量对等
• 违约责任应与实际损失、合理举证和合同整体责任结构相协调
• fallback：
• 如保留单方紧急救济，应至少避免默认承认全部损害和任意金额违约金

10. 返还、删除与留存

• 默认立场：重点争取
• 红线情形：
• 要求立即删除一切副本，但不允许合规备份、留档或法定留存
• 建议方向：
• 约定返还/删除义务，同时允许法律、审计、备份场景下的受限留存
• fallback：
• 留存副本不得再用于其他目的

PRC 场景特别提示

• 如果信息包含客户名单、价格策略、技术文档、源代码、模型参数，优先按商业秘密高敏级处理
• 若双方存在竞争关系，残余记忆、用途扩张、反馈归属要默认更严
• 不要把 NDA 写成事实上的竞业限制协议

输出优先级

对 NDA，报告优先展示： 1. 保密定义与例外 2. 使用目的限制 3. 残余记忆 4. 禁招揽 5. 救济与责任 6. 管辖与争议解决

PRC Procurement Redlines

适用于中国大陆语境下的：

• 货物采购合同
• 设备采购合同
• 软硬件采购
• 采购框架协议
• 含安装、调试、维保的采购合同

主要依据方向：

• 《中华人民共和国民法典》合同编中买卖、承揽等规则
• 中国大陆交易实践中的验收、开票、付款、质保、交付分配
• 数据安全、现场安全、商业秘密和供应链管理要求

审查目标

采购合同要重点防止：

• 交付了但验收无限拖延
• 验收通过了但付款条件不闭环
• 质保与售后责任落空
• 现场、数据、安全责任悬空
• 价格、税费、变更、备件等隐性成本失控

红线清单

1. 标的、规格与技术附件

• 默认立场：红线
• 红线情形：
• 标的、型号、数量、技术标准、配置清单写不清
• 主合同与附件冲突但无优先级
• 建议方向：
• 明确规格、数量、技术附件、验收标准和附件优先级
• fallback：
• 至少固定双方确认版本和优先适用顺序

2. 交付、安装与风险转移

• 默认立场：重点争取
• 红线情形：
• 未写交付地点、运输责任、安装调试边界、风险转移节点
• 建议方向：
• 明确到货、签收、安装、试运行、初验、终验各节点责任
• fallback：
• 至少把“签收不等于验收通过”写清

3. 验收标准与默认验收

• 默认立场：红线
• 红线情形：
• 没有验收标准
• 只有采购方主观满意标准
• 无异议期限，导致无限拖延
• 建议方向：
• 量化验收标准、异议期限、整改周期、复验机制、默认验收
• fallback：
• 允许阶段验收或部分验收，不得无限期卡整体验收

4. 发票、税费与付款

• 默认立场：红线
• 红线情形：
• 付款条件只绑定“收到发票”，不写验收或资料条件
• 验收后付款账期过长且无逾期责任
• 税率、含税/不含税、票据类型写不清
• 建议方向：
• 写明价税口径、发票类型、开票时间、付款节点、逾期付款后果
• fallback：
• 至少限定账期上限，并保障无争议款及时支付

5. 质保与售后

• 默认立场：重点争取
• 红线情形：
• 无质保期、无返修时限、无备件/替换机制
• 建议方向：
• 写明质保期、响应时间、修复时限、替换/退货权
• fallback：
• 关键设备或核心系统至少保留升级处理和替代履行机制

6. 延迟交付与违约责任

• 默认立场：重点争取
• 红线情形：
• 延迟交付无责任
• 迟延责任与采购方损失完全脱钩
• 建议方向：
• 约定按日违约金、整改期限和达到阈值后的解除权
• fallback：
• 至少保留采购方在重大延迟下的替代采购或解除权

7. 现场安全、网络与数据安全

• 默认立场：红线
• 红线情形：
• 供应商进入现场但无安全义务
• 涉及系统接入、远程维护、日志抓取，但无数据和网络安全责任
• 建议方向：
• 明确现场安全、账户权限、最小授权、日志、漏洞修复、数据保密和删除责任
• fallback：
• 至少将安全事件通报、赔偿和整改义务写入

8. 知识产权与软件授权

• 默认立场：红线
• 红线情形：
• 采购标的包含软件/源码/图纸，但授权和权利范围不清
• 供应商侵权风险完全转嫁采购方
• 建议方向：
• 明确许可范围、用户数、站点数、维保升级、第三方权利保证
• fallback：
• 至少保留侵权通知、替换、修复或退款责任

9. 变更单与追加采购

• 默认立场：重点争取
• 红线情形：
• 需求变更、价格变更、交期调整没有书面流程
• 建议方向：
• 设置变更单机制，明确费用和工期调整条件
• fallback：
• 任何影响价格/工期的事项必须书面确认

10. 终止与退场

• 默认立场：重点争取
• 红线情形：
• 合同解除后无返还、拆除、退货、数据删除或移交安排
• 建议方向：
• 约定终止后的结算、退货、资料返还、账号注销、数据清除
• fallback：
• 至少保留未完成部分暂停付款和资料/系统交接义务

PRC 场景特别提示

• 含安装施工、驻场调试时，不要遗漏现场安全、第三方损害、工伤和保险安排
• 含软硬件集成时，采购合同经常夹带服务和 SaaS 成分，要同步检查数据和服务边界
• 中国大陆采购实践中，“签收”与“验收通过”必须分开写

输出优先级

对采购合同，报告优先展示： 1. 标的与技术附件 2. 验收与付款闭环 3. 质保与售后 4. 交付延误 5. 现场/数据安全 6. 终止与移交

PRC SaaS Redlines

适用于中国大陆语境下的：

• SaaS 订阅协议
• 云服务协议
• 平台服务条款
• 含 API、账号、控制台、托管数据的服务协议

主要依据方向：

• 《中华人民共和国民法典》合同编
• 《中华人民共和国个人信息保护法》
• 《中华人民共和国数据安全法》
• 《中华人民共和国网络安全法》
• 国家网信办现行数据跨境规则

审查目标

SaaS 协议在中国大陆场景下最容易出问题的不是“有没有服务”，而是：

• 客户数据被过度使用
• 境外访问或出境路径不清
• SLA 写得轻、免责写得重
• 自动续费、涨价、停服、封号权失衡
• 数据导出和退出机制缺失

红线清单

1. 数据角色与用途

• 默认立场：红线
• 红线情形：
• 服务商可任意“处理、分析、共享、商业化利用”客户数据
• 数据用途覆盖训练模型、画像、营销、产品改进，但无单独边界
• 建议方向：
• 仅限履约必要范围处理客户数据
• 训练、共享、跨产品复用、营销分析需单独书面授权
• fallback：
• 至少要求聚合/匿名化、去标识、限目的、禁止识别回溯

2. 个人信息委托处理与转委托

• 默认立场：红线
• 红线情形：
• 受托处理关系、处理目的、期限、类别、保护措施、转委托规则未写
• 建议方向：
• 按 PIPL 委托处理逻辑写清双方责任
• 转委托须经客户书面同意，并要求下游承担同等义务
• fallback：
• 至少对关键分包商、云基础设施和境外关联接收方做透明披露

3. 数据跨境与境外访问

• 默认立场：红线
• 红线情形：
• 允许数据存储、备份、支持、研发、运维“在全球范围处理”
• 未说明是否存在境外访问、境外支持、境外日志分析
• 建议方向：
• 明确数据存储地、处理地、远程访问地
• 涉及跨境时，要求双方按中国大陆现行规则另行完成合规路径
• fallback：
• 先限制为未经客户书面同意不得跨境；确有必要时单列数据跨境条款

4. SLA 与服务信用

• 默认立场：重点争取
• 红线情形：
• 有可用性承诺但无测量口径、无服务信用、无连续故障补救
• 约定“计划维护/第三方原因/网络原因”过宽免责，实质清空 SLA
• 建议方向：
• 写明 uptime、测量方法、停机定义、排除项边界、服务信用或解除权
• fallback：
• 至少在重大连续故障下赋予客户解除和数据导出权

5. 停服、封号与变更权

• 默认立场：红线
• 红线情形：
• 服务商可单方修改服务、停服、封禁账号、删除数据
• 只要怀疑违规即可永久停用，且无申诉/整改
• 建议方向：
• 将停服、封号限定在明确违约、违法或安全紧急情形
• 保留通知、整改、申诉和数据导出窗口
• fallback：
• 对紧急停用后的恢复、数据保全和申诉流程做约定

6. 自动续费与涨价

• 默认立场：重点争取
• 红线情形：
• 自动续费没有提前通知
• 服务商可单方涨价并视为客户接受
• 建议方向：
• 自动续费前明确通知；涨价须双方确认
• fallback：
• 至少保留客户因涨价无责终止的权利

7. 数据导出、删除与退出协助

• 默认立场：红线
• 红线情形：
• 没有导出机制
• 合同终止即刻删库，但不给客户导出窗口
• 删除义务写得模糊
• 建议方向：
• 写明导出格式、导出时限、保留窗口、删除确认和迁移协助
• fallback：
• 至少保证可用导出和合理过渡期

8. 安全事件与审计

• 默认立场：红线
• 红线情形：
• 无安全事件通知时限
• 审计权被完全排除
• 审计权完全不受限制，影响服务商正常经营
• 建议方向：
• 写明事件通报时限、配合义务、整改计划
• 审计权限于合理范围、合理频率、保密约束下进行
• fallback：
• 可用第三方审计报告、认证、问卷替代部分现场审计

9. 责任限制

• 默认立场：红线
• 红线情形：
• 因数据泄露、保密违约、侵权、故意或重大过失仍完全限责
• 服务商免责极宽，但客户违约责任很重
• 建议方向：
• 一般责任 capped
• 对数据、保密、侵权和故意重大过失单列 carve-out 或更高子上限
• fallback：
• 即使保留 cap，也不能把核心合规违约全部压平到极低金额

10. 开源与第三方组件

• 默认立场：重点争取
• 红线情形：
• 第三方组件、子处理者、境外云资源完全不披露
• 建议方向：
• 至少披露关键第三方依赖和相关责任边界
• fallback：
• 保留重大变更通知和客户异议退出权

PRC 场景特别提示

• 若客户数据可能包含员工、消费者、用户画像、客服记录、日志、定位、设备标识，默认按个人信息或高敏数据场景处理
• “境外支持团队可访问数据”在中国大陆语境下不能只当运营问题，应单列跨境合规风险
• SaaS 协议常把数据、服务、许可、隐私政策放在多个文件里，必须做整包审查

输出优先级

对 SaaS 协议，报告优先展示： 1. 数据用途与角色 2. 数据跨境与境外访问 3. SLA 与停服权 4. 自动续费与涨价 5. 数据导出与删除 6. 责任限制

PRC Service Redlines

适用于中国大陆语境下的：

• 一般服务协议
• 技术服务、实施服务、运营服务、咨询服务
• 驻场、里程碑交付、持续性运维服务

主要依据方向：

• 《中华人民共和国民法典》合同编
• 中国大陆交易实践中的服务范围、验收、变更、成果归属、驻场与管理边界
• 涉及数据、保密、顾问/用工场景时的专项规则

审查目标

服务协议最常见的风险不是“条款少”，而是：

• 服务范围和边界模糊
• 客户配合义务未写，责任全压在服务商
• 验收与付款脱节
• 变更没有机制
• 驻场或个人化履约被写成类似劳动管理

红线清单

1. 服务范围与交付物

• 默认立场：红线
• 红线情形：
• 服务范围只写原则性表述
• 交付物、里程碑、工作说明书、响应范围不清
• 建议方向：
• 明确服务内容、排除事项、交付成果、里程碑和双方接口人
• fallback：
• 至少把“范围外事项需另行评估/变更”写清

2. 客户配合义务

• 默认立场：重点争取
• 红线情形：
• 服务效果依赖客户提供资料、接口、权限、场地，但合同不写客户配合义务
• 建议方向：
• 列明客户应提供的资料、审批、测试环境、接口、反馈时限
• fallback：
• 对客户迟延配合引起的工期顺延和责任豁免做基本约定

3. 验收与确认机制

• 默认立场：红线
• 红线情形：
• 没有验收标准
• 咨询/服务成果只能按主观满意判断
• 建议方向：
• 按里程碑、交付件清单、会议纪要、邮件确认等客观方式验收
• fallback：
• 至少设反馈期限和默认确认机制

4. 变更控制

• 默认立场：重点争取
• 红线情形：
• 客户可无限制追加需求，但费用和工期不调整
• 建议方向：
• 设置变更单机制；对范围、工期、费用和资源影响做书面确认
• fallback：
• 至少规定重大新增需求需双方书面确认后实施

5. 人员安排与替换

• 默认立场：重点争取
• 红线情形：
• 关键人员锁死但无合理替换机制
• 客户对服务商人员有过强日常管理权，接近劳动管理
• 建议方向：
• 保留合理替换权；客户仅就资质、保密、安全提出要求
• fallback：
• 如需指定核心人员，应允许因离职、疾病、内部调配进行等效替换

6. 驻场与用工重定性

• 默认立场：红线
• 红线情形：
• 个人顾问或服务人员长期驻场、固定工位、固定考勤、接受客户直接日常管理
• 建议方向：
• 强调服务关系独立性，避免写成员工化管理安排
• fallback：
• 驻场管理仅限现场安全、项目协同、信息安全，不延伸到人事管理

7. 成果归属与背景能力

• 默认立场：红线
• 红线情形：
• 所有与服务有关的成果、经验、模板、工具、方法论全部归客户
• 建议方向：
• 背景 IP、通用能力、模板、工具保留给原权利人
• 项目定制成果按范围约定权利
• fallback：
• 为客户提供限目的使用许可，而非一揽子转让

8. 费用、报销与付款

• 默认立场：重点争取
• 红线情形：
• 服务费、差旅、第三方费用承担不清
• 付款完全由客户主观确认或内部流程决定
• 建议方向：
• 写明含税口径、报销条件、付款时间、阶段结算和无争议款处理
• fallback：
• 至少保障已完成部分和已批准费用可结算

9. 保密与数据

• 默认立场：红线
• 红线情形：
• 服务过程中接触客户数据、员工数据、源代码、经营信息，但合同无保密和数据条款
• 建议方向：
• 补保密、最小访问、账号管理、资料返还删除和安全事件通报
• fallback：
• 高敏场景下至少并入单独 DPA 或数据条款附件

10. 终止与过渡

• 默认立场：重点争取
• 红线情形：
• 客户可随时终止但不支付已发生费用
• 终止后无知识移交、资料返还、未完成工作交接安排
• 建议方向：
• 写清提前终止通知期、结算规则、移交范围和过渡支持
• fallback：
• 即使保留方便解除，也应补偿已完成工作和不可撤销成本

PRC 场景特别提示

• 技术服务、咨询服务和外包服务常混用模板，必须确认究竟是“交付成果”还是“持续投入”
• 若由自然人顾问提供服务，合同不要照搬公司服务协议，否则容易漏掉用工、税务和发明归属问题
• 驻场服务中，现场安全、账号权限和数据访问要与劳动管理边界分开写

输出优先级

对服务协议，报告优先展示： 1. 服务范围与排除事项 2. 客户配合义务 3. 验收与付款闭环 4. 变更控制 5. 驻场/用工边界 6. 成果归属与保密数据

Report Template

最终报告尽量使用下面的结构。可以精简，但不要改掉核心栏目。

# 合同审查报告

## 1. 审查结论
- 合同名称：
- 合同类型：
- 审查模式：
- 签署建议：`建议签署 / 修改后可签 / 暂不建议签署 / 需补充信息后判断`
- 结论摘要：

## 2. 审查范围与依据
- 审查对象：
- 使用材料：
- 外部依据：
- 内部依据：
- 未覆盖或未取得的材料：

## 3. 关键风险摘要
| 风险ID | 等级 | 类别 | 条款 | 风险摘要 | 建议动作 |
|--------|------|------|------|----------|----------|

## 4. 逐项审查意见
### 4.1 [条款标题 / Clause ID]
- 现状：
- 问题：
- 依据：
- 影响：
- 建议：
- 备选方案：

## 5. 建议 redlines
### 5.1 [条款标题]
- 当前表达：
- 建议表达：
- 备注：

## 6. 待业务或对方确认事项
- [问题 1]
- [问题 2]

## 7. 备注与边界
- 本次审查基于：
- 未审查部分：
- 时效性说明：

使用要求

• 审查结论 必须先给出一句人能快速看懂的摘要
• 审查范围与依据 必须说明有没有公司制度、模板、红线
• 关键风险摘要 只保留最重要的 3-10 项，不要把所有小问题都塞进去
• 逐项审查意见 可以按条款顺序，也可以按风险优先级排序
• 建议 redlines 尽量给可落地文本；做不到时给方向性建议
• 备注与边界 不能省略，尤其在合同不完整、法域不明、依据不足时

Risk Taxonomy

用统一分类和分级，避免审查报告只有“高、中、低”而没有语义。

风险分类

Legal

条款可能违法、无效、不可执行，或明显与适用法律相冲突。

Compliance

条款可能引发监管、牌照、数据、出口管制、反商业贿赂、行业规范等合规风险。

Commercial

定价、付款、验收、排他、期限、终止、责任分配对我方明显不利，但未必违法。

Operational

交付、配合、流程、SLA、资源投入、变更、通知、审计、实施难度过高或不可控。

Financial

回款、税务、保证金、信用风险、赔偿暴露、无限责任等财务后果显著。

IP-Data

知识产权、数据权属、使用范围、成果归属、背景技术、数据导出和删除安排不清。

Governance

超授权、审批缺失、偏离模板、违反内部制度、签署流程不闭环。

严重性分级

Critical

满足任一情形：

• 明确违法或高概率违规
• 可能导致重大处罚、重大索赔、核心资产损失
• 无上限或实质接近无上限责任，且缺少对价或控制条件
• 关键权利被永久、独占或不可逆转让
• 缺少关键信息，导致根本无法判断是否可签

默认动作：

• 暂不建议签署
• 必须修改或补信息

High

满足任一情形：

• 对我方造成明显重大不利
• 发生概率较高且后果较重
• 核心商业利益、数据、安全、交付稳定性受到实质影响

默认动作：

• 修改后可签
• 给明确 redline

Medium

满足任一情形：

• 有谈判价值，但不改不一定阻断签署
• 风险可通过运营、通知、留痕、保险、审批覆盖

默认动作：

• 记录并建议优化

Low

主要是文字不一致、定义瑕疵、次要流程问题、可接受偏离。

默认动作：

• 可接受但建议顺手修订

概率与可修复性

如果用户需要更细粒度判断，可追加两个维度：

• likelihood: high / medium / low
• fixability: easy / moderate / hard

使用原则：

• 发生概率高但易修复，优先推动 redline
• 发生概率低但后果灾难性，也不能降级

风险台账写法

每条风险都应尽量写成：

典型映射示例

• “违约赔偿无上限” -> Financial, 常见为 Critical 或 High
• “数据用途允许对方任意分析和二次利用” -> Compliance 或 IP-Data
• “未约定验收即视为全部通过” -> Commercial + Operational
• “合同主体写成业务部门而非法人主体” -> Governance
• “成果归属写不清，背景 IP 可能被一并转让” -> IP-Data

Source Hierarchy

合同审查时，先判断“这是一条什么性质的依据”，再决定它能支持多强的结论。

依据层级

A. 外部强制性依据

包括：

• 法律
• 行政法规
• 部门规章
• 司法解释
• 生效判例规则或官方裁判口径
• 行业监管要求

用途：

• 证明某条款可能违法、无效、不可执行、存在监管处罚风险

B. 内部强制性依据

包括：

• 公司制度
• 审批权限表
• 合同管理办法
• 特定业务线的红线清单
• 标准模板和必备条款要求

用途：

• 证明某条款可能无法通过内部审批
• 证明某项安排偏离公司底线或授权边界

注意：

• 内部制度不能覆盖或替代法律
• 但内部制度仍可能决定“能不能签”

C. 交易性依据

包括：

• 行业惯例
• 市场常见条款
• 谈判经验
• 我方商业偏好

用途：

• 解释某条款是否失衡、是否偏离常见安排、是否值得争取

注意：

• 这类依据不能直接写成“法律要求”

记录要求

每条依据尽量记录：

• 标题
• 来源层级
• 发布日期
• 生效日期
• 适用法域
• 它支持的具体审查点

结论强度

按证据强度输出结论：

• 确定风险：有明确法律、监管或公司制度支持
• 较高概率风险：依据较强，但仍依赖合同解释或事实前提
• 商业不利项：不一定违法，但明显偏向对方
• 待确认：信息不足，不能下硬结论

冲突处理

法律与公司制度冲突

• 先指出法律红线
• 再说明内部流程上应如何处理
• 不得为了迁就内部模板而淡化违法风险

法律依据之间冲突

• 优先使用更高位阶、更新、与具体场景更贴近的依据
• 无法可靠判断时，降低结论强度并写明不确定性

公司制度之间冲突

• 优先最新版本
• 优先专门规则而非一般规则
• 如仍冲突，标记需内部确认

引用写法

审查报告中引用依据时，优先使用这类表达：

• “依据《[名称]》第 X 条，……”
• “根据 [机构] 于 [日期] 发布的 [文件名称]，……”
• “按用户提供的《[公司制度名称]》第 X 节要求，……”

如果拿不到准确条次：

• 可以概述依据内容
• 但必须明确“未核到具体条号”或“基于当前可得版本判断”

不能做的事

• 伪造公司制度、审批规则或监管口径
• 把模板偏好写成法律义务
• 用没有日期的网络二手总结替代正式依据
• 在法域不明时直接给出高度确定的法域结论

Standard Redlines

这是一套通用企业立场的红线库，适合作为“没有公司内部规则时的默认起点”。

不要把这里的内容当成强制法律结论。它们分为三类：

• 红线：原则上不接受，除非管理层或法务负责人明确批准
• 重点争取：优先谈判，谈不下来也要记录风险和补救条件
• 可接受但需知悉：可以接受，但应写入风险摘要

使用方法

对每个问题按以下顺序输出： 1. 当前条款问题 2. 默认立场：红线 / 重点争取 / 可接受但需知悉 3. 目标修改方向 4. 最低 fallback 5. 若接受 fallback，需要的补充条件

如果默认按中国大陆法语境审查：

• 同时读取 prc-defaults.md
• 若合同类型已知，优先读取对应专项文件：
• NDA： prc-nda-redlines.md
• 采购： prc-procurement-redlines.md
• SaaS： prc-saas-redlines.md
• 服务： prc-service-redlines.md
• 对格式条款、免责条款、数据出境、商业秘密和顾问/用工边界默认更保守
• 输出里区分“法律/合规底线”和“商业偏好”

通用红线项

1. 责任上限

• 默认立场：红线
• 不接受：
• 无上限赔偿
• 赔偿上限仅对一方适用
• 将间接损失、利润损失、商誉损失全部纳入常规赔偿
• 目标修改方向：
• 总赔偿责任以过去 12 个月已支付或应支付合同价款为上限
• 最低 fallback：
• 对一般违约设总 cap
• 对保密、数据、IP 侵权、故意或重大过失设置 carve-out 或更高子上限

2. 间接损失

• 默认立场：红线
• 不接受：
• 双方均未定义的“任何间接损失、后果性损失、利润损失”无限承担
• 目标修改方向：
• 双方互相排除间接损失、利润损失、商誉损失、惩罚性赔偿
• 最低 fallback：
• 至少为我方争取间接损失排除

3. 付款条件

• 默认立场：重点争取
• 不接受：
• 验收后超长账期
• 付款条件与对方单方满意度绑定
• 开票和付款关系写得导致实际无法回款
• 目标修改方向：
• 明确验收时点、开票条件、付款节点和逾期违约责任
• 最低 fallback：
• 账期有明确上限
• 逾期付款至少保留催告和暂停履行权

4. 验收机制

• 默认立场：重点争取
• 不接受：
• 完全没有验收标准
• 对方可无限期拖延验收
• 无理由拒绝验收
• 目标修改方向：
• 写明验收标准、提交方式、异议期限、补救周期、默认验收
• 最低 fallback：
• 设定异议期限；逾期未反馈视为通过或阶段性通过

5. 自动续约与单方变价

• 默认立场：重点争取
• 不接受：
• 自动续约没有提前通知退出期
• 对方可单方涨价、改单价、减服务
• 目标修改方向：
• 自动续约需提前通知且我方可无责退出
• 价格变更须经双方书面确认
• 最低 fallback：
• 至少保留我方因涨价而无责解约的权利

6. 单方解除权

• 默认立场：红线
• 不接受：
• 对方可任意解除，我方无对应权利或补偿
• 目标修改方向：
• 双方基于同等条件拥有解除权
• 最低 fallback：
• 对方 convenience termination 应补偿已发生费用、已完成工作及合理退出成本

7. 知识产权归属

• 默认立场：红线
• 不接受：
• 我方背景 IP、通用工具、know-how、预先存在成果被一并转让
• 对“改进”“衍生”“反馈”定义过宽导致隐性让渡
• 目标修改方向：
• 背景 IP 各自保留
• 项目成果按明确范围约定
• 通用能力、工具、模型、方法论不随项目转移
• 最低 fallback：
• 给对方非独占、不可转让、限目的使用许可

8. 数据使用与审计

• 默认立场：红线
• 不接受：
• 对方可任意使用、分析、共享我方数据
• 审计权不限次数、不限范围、不限时间
• 对方可将我方数据用于训练模型、产品优化或全球关联方共享，且没有单独授权和边界
• 目标修改方向：
• 数据用途限定在履约必要范围
• 审计需提前通知、限合理频率、限相关范围、不得影响正常经营
• 最低 fallback：
• 审计只覆盖与合同义务直接相关部分，且受保密义务约束

9. 保密义务

• 默认立场：重点争取
• 不接受：
• 保密定义过宽但例外过窄
• 保密期限无限期且无合理边界
• 允许披露对象过窄，导致实际履约困难
• 目标修改方向：
• 补齐公开、已知、独立开发、合法取得等例外
• 允许向员工、顾问、关联方按需披露
• 在中国大陆语境下，将“永久保密”收窄为核心商业秘密长期保护、其他信息合理期限保护
• 最低 fallback：
• 核心商业秘密可长期保护，其他信息限定合理期限

10. 争议解决与适用法

• 默认立场：重点争取
• 不接受：
• 完全偏离我方可承受范围的异地管辖或陌生法域
• 目标修改方向：
• 采用我方熟悉、执行便利、成本可控的争议解决地
• 最低 fallback：
• 至少确保语言、程序、送达和执行风险可控

合同类型专项红线

NDA

• 残余记忆条款允许对方实质绕开保密义务：红线
• 禁招揽期限过长或对象过宽：重点争取
• 单方 injunctive relief 且缺少对等性：重点争取

SaaS

• 服务商可任意使用客户数据训练模型：红线
• 无数据导出与迁移协助：重点争取
• SLA 失效时没有服务信用或补救：重点争取

采购/服务

• 付款与验收机制完全失衡：重点争取
• 质量保证、返修、替换、延迟责任缺失：重点争取
• 供应商现场安全与数据安全责任缺失：红线
• 发票、税费、验收、付款先后关系写不清：重点争取

License / IP

• 独占或永久许可没有明确额外对价：红线
• 对方可自由再许可：重点争取
• 侵权责任全部由我方兜底：红线

接受 fallback 时的补救条件

如果部分红线因交易强势地位无法完全拿回，至少考虑以下补救：

• 提高价格或增加预付款
• 缩短期限或降低范围
• 增加通知、整改、补救期
• 增加责任上限或 carve-out 对称性
• 增加数据删除、返还、迁移和退出协助
• 要求管理层或业务负责人书面确认风险承担

输出示例

### R-03 责任限制失衡
- 默认立场：红线
- 当前问题：对方对全部损失免责，但要求我方承担无上限赔偿。
- 目标修改：双方一般责任均以过去 12 个月已支付合同价款为上限，并互相排除间接损失。
- 最低 fallback：对一般违约设 cap；对保密、数据和 IP 侵权设更高子上限。
- 补充条件：如无法完全修改，应提高对价并升级内部审批。