企业买到的不是一个系统，而是一条供应链
一个客户助手可能调用外部模型，由集成商编排，再读取 CRM、知识库和工单系统。页面上只有一个对话框，背后却有多家公司。只要其中一个接口、权限或数据字段变化，最终回答就可能出错。
事故发生时，模型方说请求已正常返回，CRM 方说接口可用，集成商说上游数据为空。每一方从自己的组件看都没问题，但客户面对的是整条流程失败。没有完整结果负责人，多供应商就容易变成多处推诿。
上线前先画一张责任与数据流图
把用户请求从进入到完成经过的系统、数据、负责人和外部依赖画出来。每个节点写清谁维护、谁能看日志、变更由谁通知、故障先找谁。图不需要复杂，能让业务负责人和供应商共同看懂最重要。
同时区分组件责任和业务结果责任。模型供应商负责服务可用与约定接口，业务系统供应商负责数据输出，集成商负责流程编排；企业内部仍需有人对“客户问题是否被正确处理”负责。
- 列出模型、数据源、接口、编排和人工节点。
- 为每个节点标明维护、审批、监控和通知责任。
- 指定一位能够协调完整业务结果的总负责人。
合同里要写日志、变更和响应，不只写功能
很多合同详细列了功能，却没有说明出错后能拿到什么日志、第三方升级是否提前通知、谁负责复现、不同等级事件多久响应。等到生产事故时再谈，往往已经来不及。
企业至少要确保能追踪一次请求使用了哪个版本、读了哪些来源、调用了哪些工具、在哪一步失败。日志访问还要符合权限和隐私要求，不能为了排错让所有供应商看到全部客户数据。
联调验收要故意制造跨系统问题
正常流程跑通只能证明接口能连。验收还要模拟字段缺失、权限过期、模型超时、重复提交、业务系统升级和人工未接单，观察错误由谁发现、是否能降级、通知能否到人。
跨供应商演练能提前暴露责任空白。例如模型超时后是否自动重试，重试会不会重复创建订单；CRM 返回旧字段时由谁更新映射。把这些问题放在上线前解决，比事故中临时拉群有效得多。
企业必须保留替换和退出能力
多供应商合作会变化，模型可能切换，集成商可能更换，业务系统也会升级。企业应保留提示与流程配置、评测集、数据字典、日志和接口说明，并约定交接格式，避免关键知识只存在供应商人员电脑里。
责任清楚不是为了出错后找人追责，而是让问题有人接、信息能流动、系统可以恢复。企业 AI 越深入业务，多方协作越常见，提前把边界和完整结果负责人定下来，才是定制项目能够长期运行的基础。
要点总结
- 需要，组件可以分工，但必须有人协调完整业务结果、事件处理和跨方变更。
- 至少应能追踪版本、来源、工具调用、关键步骤和失败位置，同时遵守权限与隐私要求。
- 异常演练能发现责任空白、降级缺口和重复执行风险，正常演示通常看不到这些问题。
参考来源说明
本文围绕“模型、集成商和业务系统来自三家，AI 出错到底谁负责”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。