AI企业法律风险地图(四十):从研发、训练、上线到并购退出——企业法律风险总表

一、写完三十九篇以后，企业仍然需要一张AI风险总图

（一）AI风险正在被割裂管理

目前企业处理AI风险时，常见做法是：数据问题交给数据合规团队，算法备案交给产品或政府事务部门，客户合同交给法务，网络安全交给信息安全部门，模型效果交给研发，训练数据交给数据团队，模型采购交给采购部门，事故发生后再由客服、公关和技术团队处理。

每个部门都在处理一部分问题，却很少有人对完整风险链负责。

问题在于，AI项目并不会按照企业部门边界运行。

一份客户文件，可能同时涉及合同资料、个人信息、商业秘密、知识库来源和模型评测样本。

一个第三方模型API，可能同时涉及采购合同、数据跨境、服务连续性、知识产权、输出责任和客户承诺。

一个Agent功能，可能同时涉及权限设计、数据访问、人工确认、业务审批、事故恢复和责任追溯。

如果每个部门只看自己负责的部分，就容易出现三个问题。

1、立项时没人判断项目是否应该做

业务部门先提出需求，研发先接入模型，数据团队先导入资料，等到上线或者签客户时，才让法务介入。

此时即使发现客户数据无权训练、知识库含有敏感信息、产品属于高风险场景，整改成本也已经很高。

2、合同承诺和技术能力相互脱节

销售可能承诺数据不出境、绝不用于训练、模型完全自研、准确率达到95%，研发却依赖境外API，客户输入进入上游平台，模型实际基于开源项目微调，所谓准确率也只在特定测试集上成立。

事故发生后，企业不能用“销售不知道技术架构”或者“研发没看过客户合同”对抗客户。

3、事故发生后没有完整证据链

企业可能无法说明使用了哪个模型版本、调用了哪个知识库、谁修改了提示词、谁批准了自动执行、谁审核了输出、错误发生在哪一环。

没有这些证据，既难以向客户解释，也难以向供应商追责。

（二）企业需要的是总控框架

AI治理的关键，不是增加一份原则性制度，而是建立一套贯穿项目全周期的总控框架。

这套框架至少要回答：

谁发起项目；

谁识别风险等级；

谁批准数据和模型使用；

谁审查供应商；

谁决定产品上线；

谁对客户作出承诺；

谁负责持续监测；

谁处理事故；

谁留存证据；

谁承担最终管理责任。

只有这些问题有明确答案，AI合规才能从一次法务审查，变成真正的企业管理机制。

二、AI风险应按生命周期管理

（一）传统法律分类不适合直接管理AI项目

从法律专业角度，AI风险可以分别归入合同、知识产权、个人信息、数据安全、网络安全、消费者权益、产品责任、劳动用工、反不正当竞争、出口管制和公司并购。

但一个AI项目通常同时涉及多个领域。

例如，一款企业知识库产品，可能同时涉及客户文档处理、第三方基础模型调用、RAG知识库版权、模型幻觉、客户数据训练、上游模型停服、合同终止后的知识库删除，以及并购后数据能否继续使用。

如果这些问题分别交给不同专业团队，而没有统一项目负责人，风险之间的联系就会被切断。

（二）更适合企业的七阶段框架

企业可以把AI项目拆成七个阶段：

战略和立项；
数据和知识库；
模型研发与采购；
产品设计与上线；
销售、采购与项目交付；
持续运营与事故处理；
出海、融资、并购与退出。

每个阶段都应设置：

风险识别；

审批主体；

必备材料；

合同安排；

技术控制；

证据留存；

退出机制。

AI治理不是等项目完成后再由法务统一审查，而是在数据进入模型前、模型接入系统前、产品对外上线前、销售作出承诺前、Agent获得权限前，分别设置控制门槛。

三、战略和立项阶段：先决定项目能不能做

（一）AI资产可能从一开始就不属于公司

AI企业早期常见问题包括：

创始人在原单位任职期间使用原单位资源开发模型；

代码保存在个人GitHub或者个人云账号；

模型API、域名和云服务由个人注册；

外包团队未签成果归属协议；

高校合作成果归属不清；

员工使用个人设备和账号训练模型；

创始团队没有明确早期技术成果归属。

这些问题平时可能不明显，但在融资、并购、核心人员离职和团队分裂时会集中爆发。

企业应从一开始确保代码仓库、模型权重、训练脚本、域名、云账号、API账号、数据库、知识库和客户项目资料由公司控制，并通过劳动合同、保密协议、成果归属文件、外包合同和实际交接记录固定权利链。

（二）立项不能只看商业价值

立项阶段至少要判断：

是否处理个人信息或者敏感个人信息；

是否涉及未成年人；

是否涉及医疗、金融、招聘、教育或者公共安全；

是否影响自然人重大权益；

是否属于自动化决策；

是否接入生产系统或者现实设备；

是否允许Agent自动执行；

是否可能造成生命健康或者重大财产损失；

是否需要科技伦理审查、专家复核或者其他程序。

同样是AI问答，内部办公助手和面向未成年人的心理陪伴产品风险完全不同。

同样是Agent，自动整理会议纪要和自动付款、自动部署代码，也不能适用同一套审批标准。

（三）公司主体、技术主体和数据处理主体必须厘清

AI项目中经常出现：

境内公司签客户合同，境外主体实际提供模型；

技术由关联公司掌握，收入由目标公司取得；

数据由客户提供给A公司，实际由B公司处理；

员工劳动关系在一家公司，成果由另一家公司使用；

产品运营主体、客户合同主体和备案主体不一致。

主体不一致并不当然违法，但必须通过关联协议、知识产权许可、数据处理协议、分包条款和责任追偿机制补足。

企业至少要说清四件事：

谁与客户签约；

谁实际处理数据；

谁控制模型；

谁承担对外责任。

（四）立项阶段的四项核心控制

1、建立AI项目申报制度

凡接入外部模型、使用数据训练、建设知识库、上线自动决策或者开放Agent工具调用，都应进入申报流程。

2、建立风险初筛表

初筛应覆盖使用场景、用户类型、数据类别、模型来源、部署方式、自动化程度和潜在损害。

3、实行红、黄、绿分级

绿色项目走简化流程；黄色项目进行法务、数据和安全审查；红色项目由管理层审批，并视情况开展科技伦理审查、专家评估和安全测试。

4、把合规成本纳入预算

项目预算不能只计算模型费和开发费，还应包括数据授权、安全检测、人工审核、日志存储、内容治理、应急响应和退出迁移成本。

四、数据和知识库阶段：先证明能不能用

（一）训练数据不是拿到就能用

企业使用任何训练、微调、评测或者知识库数据前，应回答：

数据从哪里来；

谁有权提供；

是否允许训练；

是否允许商业使用；

是否允许形成衍生模型；

是否允许跨客户复用；

是否允许境外访问；

是否包含个人信息；

是否包含商业秘密；

是否存在删除、撤回和退出要求。

数据来源合法只是第一步。

一份数据库可能合法购买，但许可只允许内部查询，不允许模型训练。

公开网页可以正常访问，也不当然意味着可以长期抓取并形成商业训练集。

客户可以向供应商提供项目资料，也不当然有权允许供应商把其中第三方个人信息和商业秘密用于通用训练。

（二）客户数据不能自动变成AI企业的数据资产

客户向AI企业提供数据，通常是为了项目实施、本客户模型微调、知识库建设或者业务处理。

这不等于供应商可以将数据用于：

训练通用模型；

服务其他客户；

进入集团数据池；

出境处理；

公开展示；

合同终止后继续保留。

客户数据用途至少应区分：

为本客户提供服务；

为本客户优化系统；

形成不含客户可识别信息的统计改进；

训练行业模型或者通用模型；

跨客户、关联方或者集团复用。

“供应商可为优化服务使用客户数据”不能覆盖全部用途。

技术上能够训练，也不等于法律上已经取得训练权。

（三）RAG知识库是最容易被忽视的风险区

企业知识库常见问题包括：

文件来源不清；

新旧版本混杂；

废止制度未清理；

客户知识库隔离失败；

员工随意上传资料；

商业秘密进入非受控系统；

外部网页、PDF含有隐藏提示词；

向量库和缓存无法删除；

知识库没有引用来源；

Agent可以无差别读取高敏感文档。

知识库不是共享盘的简单复制。

普通文件存储错误，影响可能有限；一旦进入知识库，错误、过期或者恶意内容会被模型持续检索和放大。

企业应为重要文档标注来源、权利人、版本、生效时间、失效时间、保密等级、访问人员，以及是否可用于对外答复和Agent执行。

（四）至少建立四套台账

1、数据来源台账

记录数据名称、来源主体、取得方式、合同依据和责任人。

2、数据授权用途台账

记录是否允许训练、评测、商业化、跨客户复用、集团共享和跨境访问。

3、知识库版本台账

记录文档版本、入库时间、审核人员、适用范围和废止情况。

4、数据删除和退出台账

记录删除请求、合同终止、客户撤回授权、备份覆盖和向量库清理。

企业真正需要的，是能够随时回答数据从哪里来、现在在哪里、用到了什么地方、能不能删除。

五、模型研发与采购阶段：厘清来源、权属和依赖

（一）先判断模型到底是谁的

模型可能来自：

完全自研；

开源模型微调；

第三方商业API；

客户提供；

高校或者研究机构合作；

外包团队开发；

创始人个人资产；

境外关联方提供；

多模型组合和路由；

开源模型加LoRA、RAG封装。

不同来源对应不同的权属、授权和责任。

完全自研模型要审查员工和外包成果归属。

开源模型要审查许可证。

第三方API要审查服务条款、数据使用和连续性。

高校合作要审查共同成果、论文发表和商业化权限。

境外关联方提供模型，还要审查跨境数据、技术转移和实际控制。

（二）“自研”必须拆解到具体层级

至少要区分：

基础模型；

微调模型；

模型权重；

训练代码；

推理框架；

系统提示词；

RAG系统；

Agent工作流；

数据和评测集；

模型安全规则。

一家企业可能没有自研基础模型，但自研了行业微调、知识库架构、提示词和工作流。这仍然具有技术价值，但不能对外宣传整个模型完全自研。

（三）开源不等于免费和无责任

企业使用开源模型、代码和数据集时，应审查：

是否允许商业使用；

是否允许SaaS或者托管服务；

是否允许再分发；

是否要求公开源代码；

是否限制模型输出用途；

是否限制竞争性使用；

是否要求保留声明；

衍生模型能否闭源；

是否存在地域或者行业限制；

不同许可证是否冲突。

开源合规不能只依赖研发口头判断。

企业应建立开源清单，记录名称、版本、许可证、使用方式、修改情况和合规结论。

（四）模型采购不能只看效果和价格

采购至少要审查：

模型权属；

训练数据来源；

客户输入是否用于供应商训练；

模型版本变更；

SLA；

限流和并发；

涨价机制；

停服和下线；

数据迁移；

输出责任；

模型后门和安全缺陷；

地域、行业和出口管制限制。

采购合同中的限制必须同步给销售和产品。

如果上游不保证输出准确，企业却向客户承诺绝对正确，就会形成责任倒挂。

如果上游禁止转售，企业却将API包装后对外收费，也会形成合同错配。

（五）关键供应链必须有替代方案

供应链可以分为：

一级关键依赖，一旦中断核心业务无法运行；

二级重要依赖，中断会显著影响效果、成本和客户体验；

三级辅助依赖，可以在较短时间内替换。

一级依赖必须具备：

替代方案；

数据和知识库导出；

模型迁移机制；

连续性条款；

应急预案；

必要的源代码、部署包或者配置托管。

对关键系统来说，服务中断时最重要的不是将来能否获得赔偿，而是能否继续运营和完成迁移。

六、产品设计和上线阶段：把责任做进系统

（一）AI合规不能只审一次

AI产品会经历内部测试、PoC、灰度上线、正式商用、模型升级、数据集更新、场景扩大和自动执行权限提升。

每一次重大变化，都可能改变原有风险判断。

内部助手转为公众服务，适用规则会变化。

辅助建议转为自动拒绝或者自动发送，责任等级会提高。

Agent从只读变成可以修改生产环境，也必须重新审查。

企业应建立重大变更再审查机制。

（二）区分三类AI产品

1、输出辅助型

AI提供建议，由人决定是否采纳。

2、自动决策型

AI直接参与排序、筛选、授信、推荐、审核或者拒绝。

3、自动执行型

Agent直接发送、删除、付款、部署、控制设备或者调用工具。

从输出辅助到自动执行，企业注意义务逐级提高。

辅助型产品重点是准确性提示和人工复核。

自动决策型产品还要关注公平、解释、申诉和人工干预。

自动执行型产品必须增加权限、确认、限额、日志、隔离和回滚。

（三）高风险产品不能只靠免责声明

“AI输出仅供参考”可以说明产品定位，但不能替代：

适用范围控制；

人工审核；

引用来源；

拒答机制；

不确定性提示；

纠错机制；

投诉渠道；

日志追溯；

高危场景限制。

如果企业在销售中强调AI可以替代专业人员，又在协议角落写一句“仅供参考”，很难真正免责。

（四）伦理审查要进入产品流程

对可能影响人的尊严、心理情绪、生命健康、弱势群体、重大权益、公共秩序和现实安全的项目，企业不能只问是否合法，还要判断：

是否必要；

是否有低风险替代方案；

是否会造成不公平；

是否会诱导过度依赖；

是否保留人类最终控制；

错误后能否纠正；

风险是否与商业收益相称。

伦理审查不是价值口号，而应影响产品是否上线、向谁开放、能否自动执行和是否必须保留人工控制。

（五）上线前至少完成六类测试

企业上线AI产品前，应完成：

功能测试；

效果评测；

安全测试；

数据和隐私测试；

偏见和公平性测试；

极端场景和应急测试。

Agent还应增加权限测试、工具调用测试、提示词注入测试、人工确认测试、回滚测试和生产环境隔离测试。

测试结果、问题清单、整改记录和上线批准都应留痕。

七、销售、采购和项目交付阶段：把不确定性写进合同

（一）AI销售最危险的是过度承诺

常见高风险承诺包括：

百分之百准确；

完全替代人工；

适用于所有场景；

保证业务收益；

客户数据绝不被使用；

模型永远不会停服；

系统不会产生幻觉；

产品完全自研；

任何问题均由供应商负责。

销售话术、投标文件、技术方案和演示材料都可能影响合同解释。

涉及准确率、数据使用、模型来源、安全能力和服务连续性的承诺，应由产品、研发和法务共同确认。

（二）AI项目合同必须写清楚十件事

项目是PoC还是正式交付；

交付物是什么；

测试集和评测方法是什么；

准确率等指标如何计算；

客户应提供什么数据和配合；

模型和第三方依赖是什么；

输出是否需要人工审核；

验收不通过是否先整改；

需求变更如何处理；

退费、解除和赔偿条件是什么。

合同如果只写“交付智能系统，客户验收合格后付款”，项目失败后双方只能围绕“好不好用”争论。

（三）客户数据用途必须分层

合同应区分：

为本客户提供服务；

为本客户优化模型；

脱敏后改进产品；

训练通用模型；

跨客户复用；

集团共享；

境外访问；

案例展示；

合同终止后保留；

并购后继续使用。

法务还应要求技术团队确认实际数据流。

合同写着数据不出客户环境，研发却调用外部模型，合同条款就失去真实性。

（四）AI项目失败不当然等于供应商违约

应判断：

供应商是否未完成核心功能；

是否未达到明确指标；

客户数据是否合格；

客户是否及时配合；

需求是否发生变化；

上游服务是否异常；

是否存在合理整改机会；

是否已经影响合同目的。

供应商应保留需求确认、数据评估、客户延期、测试报告和需求变更记录。

客户应保留供应商承诺、错误样本、验收意见和整改通知。

（五）合同必须预留退出机制

包括：

数据导出；

知识库迁移；

模型和专属成果处理；

日志保留；

删除证明；

过渡期服务；

新供应商对接；

供应商停服或者倒闭处理。

企业采购AI服务时，不能只审查如何上线，也要审查如何退出。

八、持续运营和事故处理阶段：上线以后才是真正的风险期

（一）风险会随着运营持续变化

运营阶段会不断发生：

模型升级；

数据更新；

知识库变化；

客户场景扩大；

输出错误；

侵权投诉；

数据泄露；

Agent误操作；

上游停服；

监管要求变化。

重大模型升级、知识库批量更新、Agent权限提升和业务场景扩展，都应触发重新评估。

（二）输出错误后的责任取决于控制力

责任判断应回到七个问题：

谁设计模型和产品；

谁提供数据；

谁设置使用场景；

谁审核输出；

谁决定对外发布；

谁授予Agent权限；

谁能够阻止和纠正错误。

供应商、客户、最终用户、上游模型方和人工审核人员，都可能承担不同责任。

（三）Agent风险的本质是权限风险

Agent事故通常不是因为AI突然失控，而是因为：

权限过大；

没有人工确认；

外部内容被当成可信指令；

没有工具白名单；

没有操作限额；

没有日志；

没有回滚；

测试环境和生产环境未隔离。

企业应坚持从只读、草稿、人工确认、低风险自动执行逐步升级。

删除、付款、审批、外发、部署和生产配置修改，应设置更高审批门槛。

（四）事故发生后，要同步启动技术和法律流程

技术流程包括停止服务、隔离数据、回滚版本、冻结权限、恢复备份和修复漏洞。

法律流程包括固定日志、保留模型和数据版本、识别责任主体、审查合同、评估通知义务、计算损失和采取索赔措施。

技术团队不能为了恢复系统而覆盖日志。

法务也不能只忙于发函，而忽视损害仍在扩大。

（五）企业应建立事件分级

一级一般事件：个别错误输出，未造成实际损失。

二级重要事件：客户投诉、业务中断、数据误用或者批量错误。

三级重大事件：个人信息泄露、重大财产损失、未成年人或者生命健康风险、大规模内容传播和生产安全事故。

不同级别应对应不同上报、管理层介入、客户通知、监管评估和证据保全机制。

九、出海、融资、并购和退出阶段：能交割的才是真资产

（一）AI出海首先要画四张图

企业出海前应画出：

模型部署图；

数据流向图；

客户和用户角色图；

上游供应链图。

只有看清这四张图，才能判断模型和数据在哪里、谁是提供者、谁是部署者、谁决定数据处理目的、谁承担当地责任。

（二）股权交割不等于AI能力交割

买方需要确认：

模型能否转移；

数据能否继续使用；

客户是否同意控制权变更；

上游模型是否继续服务；

技术是否受出口管制或者地域限制；

核心团队是否留任；

模型和数据能否进入买方集团；

目标市场是否允许继续运营。

公司股权可以完成变更，不代表客户数据、第三方模型、开源组件、云资源和核心技术都能自动转移。

（三）AI公司估值不能只看跑分

真正能进入估值的AI资产，应满足：

权属清楚；

数据来源合规；

授权范围充分；

可持续使用；

可迁移；

可复制；

可证明收入贡献；

合规成本可控。

不能合法、稳定、持续使用的模型和数据，不是完整可交易资产。

（四）尽调风险必须进入交易机制

AI尽调发现的风险，应分别进入：

交割条件；

陈述与保证；

披露函；

交割后承诺；

专项赔偿；

托管款；

尾款；

业绩付款；

价格调整；

高风险资产剥离。

核心模型归属未解决，不能只依赖事后赔偿。

客户数据无权继续训练，不能等交割后再处理。

重点客户续费不确定，更适合通过业绩付款分担。

（五）不能靠赔偿修复的问题，应在交割前解决

例如：

核心模型不属于目标公司；

客户数据无权继续使用；

关键客户不同意交易；

上游模型交易后停服；

核心技术无法转移；

产品无法合法持续运营。

这些问题即使获得赔偿，也无法恢复交易价值。

十、企业AI治理需要五条责任线

（一）管理责任线

管理层负责确定AI战略、批准高风险项目、配置治理资源、设定风险偏好，并对重大事故承担最终管理责任。

（二）产品技术责任线

产品和研发负责模型选择、数据和知识库使用、产品边界、权限设计、人工确认、日志、回滚和安全测试。

法务不能用合同文字弥补一个没有日志、没有权限控制的系统。

（三）法务合规责任线

法务合规负责项目风险定性、合同和授权审查、适用程序判断、高风险场景控制、事故取证、出海和并购风险分配。

法务不应代替产品、研发和业务承担全部AI风险。

（四）业务运营责任线

业务部门负责使用场景、客户承诺、数据提供、人工审核、对外发布、用户投诉和异常识别。

合同约定只作内部辅助，业务却直接对外发布，责任不能全部推给供应商或者法务。

（五）供应链责任线

采购和供应商管理部门负责模型采购、上游依赖、SLA、知识产权条款、服务连续性、供应商审计和退出方案。

关键AI供应商不能只在采购时审查一次，还应持续关注财务稳定性、安全事件和产品下线风险。

十一、企业至少应具备十二份AI治理文件

《AI项目管理制度》；
《AI项目风险初筛表》；
《AI项目分级和审批规则》；
《训练数据来源及授权台账》；
《模型、开源组件和上游供应商清单》；
《AI伦理审查和高风险评估规则》；
《AI产品上线审查表》；
《AI客户合同标准条款》；
《AI供应商采购审查清单》；
《AI输出审核与Agent权限管理制度》；
《AI事故响应和证据保全预案》；
《AI服务退出、数据删除和业务连续性方案》。

计划融资、并购或者出海的企业，还应增加AI资产清单、客户数据授权矩阵、开源合规报告、AI监管事项清单、模型权属文件和历史投诉事故清单。

文件数量不是目标。真正的目标，是让每份文件都有负责人、有记录、有技术系统支持，并能在项目中执行。

十二、企业AI法律风险总表：按生命周期排查

（一）战略与立项

1、高风险场景未识别

责任部门：管理层、业务、法务合规。

核心材料：项目申报表、风险初筛表。

控制动作：风险分级、伦理评估、管理层审批。

可能后果：项目被叫停或者高成本整改。

2、核心资产由个人控制

责任部门：创始团队、研发、法务。

核心材料：资产清单、成果归属文件、账号清单。

控制动作：代码、模型、域名和云资源公司化。

可能后果：融资受阻、人员离职后业务中断。

3、运营主体和技术主体不一致

责任部门：管理层、法务、财务。

核心材料：主体关系图、关联协议。

控制动作：明确授权、数据处理和责任关系。

可能后果：合同无权履行、资产和收入错位。

（二）数据和知识库

1、训练数据来源和授权不足

责任部门：数据、研发、法务。

核心材料：数据台账、授权文件。

控制动作：来源审查、用途限定、版本管理。

可能后果：模型重训、删除和第三方索赔。

2、客户数据被纳入通用训练

责任部门：产品、研发、交付、法务。

核心材料：客户授权矩阵、训练记录。

控制动作：分层授权、训练池隔离。

可能后果：客户解除、索赔和模型价值受损。

3、知识库文件过期或者来源不明

责任部门：业务、知识库管理员、法务。

核心材料：入库清单、版本台账。

控制动作：入库审批、废止清理、引用展示。

可能后果：AI持续引用错误依据。

4、不同客户知识库隔离失败

责任部门：研发、安全、交付。

核心材料：权限矩阵、访问日志。

控制动作：分区、独立索引和访问审计。

可能后果：商业秘密和客户数据泄露。

（三）模型研发与采购

1、模型权属不清

责任部门：研发、法务、人力资源。

核心材料：模型清单、成果归属文件。

控制动作：员工、外包和合作机构成果转让。

可能后果：权属争议、融资和并购受阻。

2、开源许可证违规

责任部门：研发、采购、法务。

核心材料：开源清单、许可证。

控制动作：商业使用、托管、再分发和闭源审查。

可能后果：组件替换、代码公开或者第三方索赔。

3、模型存在后门和安全缺陷

责任部门：研发、安全、采购。

核心材料：模型版本、权重哈希、安全报告。

控制动作：后门测试、第三方检测和版本留痕。

可能后果：数据泄露、系统异常和高风险业务失控。

4、上游模型停服或者限流

责任部门：采购、技术、业务连续性团队。

核心材料：SLA、连续性方案。

控制动作：替代模型、多供应商和迁移演练。

可能后果：客户服务中断和合同违约。

（四）产品设计与上线

1、适用规则判断错误

责任部门：产品、法务合规。

核心材料：业务定性说明、监管清单。

控制动作：备案、评估、标识和内容治理审查。

可能后果：整改、下架和监管责任。

2、输出错误和幻觉

责任部门：产品、研发、业务。

核心材料：效果评测、使用说明。

控制动作：引用、拒答、人工复核和纠错。

可能后果：客户损失、违约和专业责任。

3、自动化决策不公平

责任部门：产品、数据、合规。

核心材料：公平性测试、申诉机制。

控制动作：人工干预、解释和纠错。

可能后果：歧视投诉和重大权益争议。

4、Agent权限过大

责任部门：产品、研发、安全。

核心材料：权限矩阵、审批记录。

控制动作：最小权限、确认、限额、日志和回滚。

可能后果：删库、付款、外发和生产事故。

（五）销售和交付

1、销售过度承诺

责任部门：销售、产品、法务。

核心材料：报价、方案、宣传和沟通记录。

控制动作：销售口径审批。

可能后果：验收、退费和赔偿争议。

2、PoC与正式交付混淆

责任部门：销售、交付、法务。

核心材料：阶段计划、验收标准。

控制动作：里程碑、分阶段付款和退出安排。

可能后果：试点失败被认定为正式项目违约。

3、客户需求持续变更

责任部门：交付、产品、法务。

核心材料：需求清单、变更单。

控制动作：书面确认并同步调整工期、费用和指标。

可能后果：延期、拒付和范围争议。

（六）持续运营与事故处理

1、模型升级改变产品表现

责任部门：研发、产品、运营。

核心材料：版本记录、回归测试。

控制动作：重大变更再审查和灰度上线。

可能后果：SLA下降和客户投诉。

2、AI输出对外造成损失

责任部门：业务、运营、法务。

核心材料：输入输出、审核和发布记录。

控制动作：分级审核、纠错和撤回。

可能后果：侵权、违约和商誉损失。

3、Agent自动执行错误

责任部门：安全、产品、业务。

核心材料：调用链、权限和确认日志。

控制动作：停机、回滚、证据保全和责任分析。

可能后果：重大财产损失和业务中断。

（七）服务退出与并购

1、数据和知识库无法导出

责任部门：采购、技术、法务。

核心材料：退出方案、格式说明。

控制动作：定期导出和迁移测试。

可能后果：供应商锁定和业务中断。

2、模型和专属成果归属不清

责任部门：产品、研发、法务。

核心材料：资产清单、权属条款。

控制动作：区分客户专属成果和供应商通用能力。

可能后果：合同终止后无法继续使用。

3、客户或者上游不接受控制权变更

责任部门：投资、销售、采购、法务。

核心材料：重点合同和控制权变更清单。

控制动作：取得同意、设置交割条件和价格调整。

可能后果：收入流失、上游停服和估值下降。

4、AI风险未进入交易条款

责任部门：投资、法务、财务。

核心材料：尽调报告、披露函、风险清单。

控制动作：交割条件、专项赔偿、托管款和尾款。

可能后果：交割后发现问题却无法追责。

企业可以在这份总表基础上，增加风险等级、责任人、整改期限、预算和完成状态，将其转化为内部AI风险台账。

十三、不同发展阶段，企业应优先解决什么

（一）初创AI企业

优先解决：

创始人和员工成果归属；

训练数据来源；

开源模型和代码；

客户合同模板；

销售宣传边界；

核心账号和资产归公司。

初创企业不必一开始搭建复杂体系，但基础权属和数据来源必须清楚。

（二）进入商业化阶段的企业

优先解决：

客户数据训练授权；

项目验收和效果指标；

上游模型依赖；

SLA和责任限制；

产品上线审查；

AI输出和投诉处理；

数据删除和退出机制。

商业化阶段的技术风险，会迅速转化为客户合同和收入风险。

（三）快速扩张中的企业

优先解决：

多客户数据隔离；

模型和知识库版本管理；

销售和交付口径统一；

Agent权限；

供应链连续性；

海外市场和跨境数据；

历史项目整改。

小规模试点中依靠人工经验控制的问题，在客户数量增加后会迅速失控。

（四）准备融资、并购或者上市的企业

优先解决：

AI资产清单；

模型权属链；

训练数据授权；

客户数据复用边界；

开源合规；

AI监管事项；

历史投诉和事故；

核心客户和上游控制权变更条款；

AI专项陈述保证和赔偿机制。

资本市场关心的不是企业是否会使用AI，而是这套能力是否属于公司、能否持续使用、能否产生收入并随交易转移。

十四、管理层审查AI项目应问十二个问题

这个AI项目解决什么业务问题？
使用什么模型，模型由谁提供？
训练、检索和评测数据从哪里来？
是否处理个人信息、商业秘密或者客户数据？
数据能否用于训练、优化和跨客户复用？
AI是提供建议，还是直接决定或者执行？
谁负责人工审核和最终决定？
模型出错、上游停服或者Agent误操作时，能否停止、回滚和追溯？
客户合同承诺是否与真实技术架构一致？
项目是否需要伦理审查、备案、评估或者其他程序？
合同终止或者供应商倒闭时，数据、模型和知识库能否迁移？
未来融资、出海或者并购时，这套AI能力能否合法、稳定、持续地交割？

如果管理层无法获得清楚答案，项目就不应直接进入正式商用。

十五、AI治理的目标，是让AI能力可用、可信、可持续、可交易

（一）AI风险不是一张静态清单

模型会升级，数据会增加，客户场景会变化，产品会从辅助工具变成自动决策，Agent会获得更多权限，企业还会出海、融资和并购。

因此，AI合规不能是一次性审查。

AI项目应持续监测、定期复核，并在重大变化时重新评估。

（二）AI治理不是法务单独负责

真正有效的治理需要：

管理层确定边界；

产品和研发把风险做进系统；

数据团队控制来源和用途；

业务部门控制销售承诺和使用场景；

采购部门控制供应链；

法务合规完成规则转化和责任分配；

信息安全负责日志、权限和应急。

法务可以设计制度和合同，但不能代替技术团队建立日志，不能代替业务部门审核对外输出，也不能代替管理层决定企业愿意承担多大风险。

（三）企业不需要保证AI永远不出错

AI治理的目标，不是保证模型永远不出错，也不是保证企业绝对没有法律风险。

真正的目标是：

风险在立项时能够被识别；

决策过程能够说明；

使用边界能够控制；

数据和模型能够追溯；

事故发生后能够停止和修复；

责任能够合理分配；

客户、投资人和监管能够验证企业已经尽到合理注意义务。

（四）整个系列最终可以归结为五个问题

1、模型是谁的；

2、数据能不能用；

3、产品能不能上线；

4、责任能不能控制；

5、资产能不能持续经营和交割。

这五个问题贯穿一家AI企业从设立、研发、训练、上线、销售、运营、出海到并购退出的全过程。

模型权属不清，企业没有技术资产基础。

数据不能合法持续使用，模型能力无法长期维持。

产品不能稳定上线，技术无法转化为业务。

责任无法控制，业务规模越大，潜在损失越高。

资产不能持续经营和交割，融资和并购估值就缺乏支撑。

AI治理不是创新的刹车，而是企业证明其AI能力可用、可信、可持续、可交易的基础设施。

诚邀您关注我的公众号✨

第一时间获取AI领域合规解读、政策动态与实操指南，助您更高效地识别风险、理解规则、推动合规落地。

也欢迎您转发、转载本文，让更多有需要的朋友及时看到。

您的关注与支持，是我持续创作的重要动力。