从基础模型转向部署生态：全生命周期治理下的企业AI权责重构

生成摘要

AI 生成，仅供参考

企业引入人工智能时，真正困难的问题正在从“哪个模型的能力更强”，转向“模型被接入业务之后，谁能控制它、证明它可靠，并在出现损失时承担什么责任”。基础模型仍是重要的技术底座，但当智能体开始调用工具、端侧设备承担本地推理、具身系统进入物理环境，竞争就不再只发生在模型参数和评测成绩上，也发生在部署、集成、安全维护与持续运营之中。

这并不意味着模型竞赛已经结束，而是说，部署生态正在成为决定AI商业化能否持续的重要战场。企业能否把技术能力变成可复用的业务流程，取决于系统在特定场景中的效果、成本和可控性；而一旦系统跨越多家供应商、多套业务系统与多个使用主体，权责划分就不能只靠一句“模型由第三方提供”来解决。

为什么部署成为新的竞争焦点

模型能力是应用的必要条件，却不是业务价值的充分条件。同一个模型在公开测试中表现出色，进入企业后仍可能因知识库过期、权限配置不当、业务数据质量不足或系统接口不稳定而无法可靠工作。对于采购方，模型回答是否流畅只是起点，能否降低流程成本、满足业务准确性要求并控制错误后果，才决定项目是否值得扩大。

这一变化来自三个相互叠加的驱动因素。

首先，应用正在从生成内容走向参与行动。一个只生成草稿的系统，即使回答错误，也可能被后续编辑发现；一个拥有工具调用权限的智能体，则可能读取敏感资料、修改业务记录，甚至触发外部操作。模型输出与现实后果之间的距离缩短，授权、确认和回滚机制的重要性随之上升。

其次，计算与控制正在分散到更多载体。端侧模型可以在设备本地处理部分任务，但本地推理并不自动等于隐私安全：数据如何采集、存储、同步和删除，仍取决于完整产品设计。具身应用还会增加物理环境中的安全问题，例如动作边界、紧急停止和设备维护。软件系统中可以撤销的一次错误，在物理场景中未必能够同样容易地补救。

最后，客户购买的不再只是模型调用能力。随着部署深入，数据接入、系统集成、身份管理、监测和运维都可能成为服务的一部分。这为专业部署商和行业服务商创造机会，但也提高了其交付复杂度。企业使用开源模型或自建环境，或许能获得更多配置自主权，同时也需要自行承担更多评估、更新和维护工作。

这是一种产业判断，而非“所有价值都将从模型转移到应用”的确定结论。模型性能、算力成本和基础设施仍会影响竞争格局；只是对于具体客户而言，基础能力必须经过部署和运营，才能转化为可衡量的收益。

全生命周期治理：从上线审批转向持续管理

AI系统的风险并不只出现在训练模型时，也不会在上线测试通过后消失。数据会变化，模型和依赖组件会更新，用户会找到最初没有预见的使用方式，业务权限也可能逐渐扩大。因此，治理需要覆盖选型、开发、集成、测试、上线、运行、变更和退役，而不是把合规视为发布前的一次性检查。

这一思路也改变了对参与主体的观察方式。一个系统可能同时涉及模型开发者、算力或技术支持方、应用服务提供者、企业使用者、设备制造商和分发平台。它们接触风险的方式不同：有的控制模型版本，有的控制数据和系统配置，有的决定用户能否接入，还有的直接掌握业务执行权限。

但“多方共担”不等于“各方平均分责”。有控制能力、作出承诺、实施具体行为并造成或扩大风险的环节，需要被分别识别。同一主体也可能同时扮演多个角色：企业既可能是外部模型的客户，也可能是面向自身客户的应用服务提供者。

监管义务与合同责任尤其需要分开看。根据相关法律实务资料，中国《生成式人工智能服务管理暂行办法》的适用，需要结合是否向境内公众提供相关生成式AI服务等因素判断；通过可编程接口提供服务，也不能当然排除服务提供者身份。反过来，仅供企业内部研发或经营使用的系统，也不应仅因使用大模型就被简单套用同一判断。深度合成等具体服务还可能涉及针对不同角色的要求。

这些规则并不能直接回答每一个项目的全部义务。跨地区、跨行业部署时，企业仍需结合法律适用范围、服务对象、功能和实际角色，由法务团队作具体判断。更重要的是，合同可以安排合作方之间的责任分配，但不能自行消除适用的法定义务，也不能当然约束受损的外部第三方。

一次错误背后，责任链可能有多长

假设一家企业部署智能体，用于检索内部知识并协助处理客户请求。某次系统引用了不该向用户展示的文件，随后智能体又根据错误信息修改了业务记录。表面上看，这是一次“AI回答错误”；深入分析，至少存在几种不同来源：

• 模型能力与说明：模型是否存在已知限制？提供方对适用场景、输出可靠性和版本变化作了什么说明或承诺？
• 知识与权限配置：源文件权限是否正确传递到检索系统？应用是否让本不应访问该文件的用户获得了结果？
• 集成与维护：检索组件、模型接口或加载组件是否存在配置错误、已知漏洞或未处理的兼容性问题？
• 业务授权：谁允许智能体修改记录？是否设置了操作范围、金额或影响程度限制？
• 人工与运营控制：高影响操作是否需要确认？异常发生后，能否暂停、追溯并恢复记录？
• 用户行为：实际使用是否超出已知适用范围？使用者是否绕过了合理设置的控制措施？

这些问题不能预设答案，也不意味着每一方都必然承担法律责任。它们的价值在于把笼统的“AI出了错”拆解为可验证的行为、控制点与证据。

例如，专业问题回答不稳定，可能首先需要检查模型能力边界、服务说明以及企业是否选择了适当场景；若故障源于平台负责维护的组件漏洞或部署配置错误，则不能仅以底层模型来自第三方为由排除平台责任。同样，平台提示模型可能产生错误，并不自动免除其已承诺的接口、版本管理或安全维护义务；客户完成上线测试，也不等于接受此后所有维护缺陷带来的风险。

建立可执行的权责分级

企业不必为每一次低风险模型调用设计最重的审批流程，但应根据后果、权限和可恢复性建立分级。以下是可供内部治理使用的工作框架，并非法定分类。

分级应看实际能力与使用环境，而不是只看产品名称。一个被称为“助手”的工具，如果能够直接发送付款指令，就不能仅因界面温和而按普通草稿工具管理；一个用于实验的机器人，如果被接入生产现场，也需要重新评估。

在此基础上，企业可以用一张简化的责任表覆盖主要环节：

表中的“主责”是为了避免内部无人牵头，并不替代对供应商、平台或其他主体法律责任的判断。实践中，同一项控制还应写明谁执行、谁批准、谁提供咨询、谁需要被通知；尤其要避免“技术团队负责AI风险”这样的笼统表述掩盖业务部门对用途和授权的决定权。

内部审计应追问什么

审计的重点不只是检查是否存在一份AI制度，而是判断制度能否对应真实系统和真实控制。一个实用的审计顺序是：先确认资产，再追踪权限和证据，最后验证异常处置。

第一，系统是否被看见

企业能否列出正在使用的模型、供应商、应用、数据来源、部署位置和业务负责人？是否知道供应商又依赖哪些对系统安全或连续性重要的第三方？对于自行接入的工具、试点项目和嵌入现有软件的AI功能，也应尽量纳入盘点。

如果连系统在哪里、由谁使用都无法确认，就很难判断哪些数据可能离开企业，或哪些业务流程已经依赖自动化输出。

第二，控制是否与风险匹配

审计人员应检查：模型能访问什么数据，能调用哪些工具，是否遵循最小必要权限；关键操作是否有人工确认；复核人员是否拥有足够的信息、时间和权限作出有效判断。仅在制度中写明“人工复核”，但实际要求员工在极短时间内批量确认，并不能充分证明控制有效。

还要关注端侧和物理场景中的特殊问题：设备离线后规则如何执行，更新失败怎么办，紧急停止由谁触发，以及设备退役时数据如何处理。

第三，证据能否支持追责和修复

至少应根据风险等级，保存必要的系统版本、配置变更、授权记录、测试结果、关键操作和事件处置记录。日志设计既要支持追溯，也应限制对敏感数据的不必要留存。

对于供应商，采购和合同管理可重点确认模型来源与许可、更新通知、故障响应、安全维护、证据提供、审计或评估安排，以及合作终止后的数据处理。无法获得某些信息时，企业应记录这一限制，并判断是否需要替代控制或调整用途，而不是默认风险不存在。

第四，变更后是否重新验证

模型替换、提示词或知识库的重要调整、工具权限扩大、设备软件更新，都可能改变原有风险。审计应检查企业是否定义了触发重新测试和审批的条件，以及发现严重异常后能否暂停功能、回退版本或切换至人工流程。

可跟踪的指标包括：已登记系统覆盖情况、高风险应用复核完成情况、权限超范围事件、重大变更后验证情况、故障发现到处置的时间，以及人工接管和回滚是否在演练中真正成功。指标应服务于发现问题，不能以“零事件”单独证明系统安全。

合规成本与业务敏捷，如何避免两败俱伤

过度治理会拖慢试验，治理不足则可能让一个小范围试点在扩大后积累难以处理的风险。两者之间的关键不是简单增减审批，而是把控制放在风险真正发生的位置。

对低风险用途，企业可以提供经过审查的工具清单、标准采购条款、数据使用规则和轻量登记流程，让团队自行开展试验。对高影响用途，则应在接入敏感数据、授予执行权限和扩大服务对象之前设置明确的升级门槛。共享的身份管理、日志、模型网关和测试工具，也有助于避免每个项目重复建设。

商业评估同样需要覆盖完整成本。模型调用费用只是其中一部分，集成、数据整理、人工复核、供应商管理、持续监测与故障恢复都会影响项目收益。如果系统节省了起草时间，却让员工花费大量时间核对或返工，企业就应重新评估其适用性，而不是只展示调用量和试点规模。

当然，治理能力本身也有边界。企业未必能看到闭源模型的全部内部机制，供应商也未必能预测客户所有业务场景。现实的做法不是承诺消除所有错误，而是明确哪些风险可以测试、哪些控制由谁掌握、哪些限制无法消除，以及超出可接受范围时是否暂停或拒绝部署。

从模型竞赛走向部署生态，改变的是企业衡量AI能力的尺度：不仅要看系统能做什么，还要看它在什么条件下能做、谁批准它去做、出了问题能否及时停下并查明原因。能够把这些问题嵌入产品、合同和日常运营的组织，才更有机会同时获得部署速度与可持续的信任。