AI 项目最怕一句话：出了问题再说
上线前，服务商往往会介绍模型效果、行业经验和交付能力。客户听完觉得方向不错，却没有继续追问异常场景：客户投诉时谁接，知识库过期时谁改，接口返回空数据时算系统故障还是业务问题，夜间任务失败要不要有人处理。等项目运行起来，双方对“维护”这个词的理解很容易分开。
服务 SLA 的作用不是把合作变成一张罚款表，而是把日常协作说清楚。企业知道什么问题应该找谁，服务商知道哪些事情属于日常支持，哪些属于新增需求，双方就能把精力放在解决问题上，而不是反复确认责任。
先按照业务影响分故障等级
故障等级不能只按技术报错判断。全员无法登录、客户被错误通知、合同流程写入错误结果，影响显然不同；某个低频报表延迟十分钟，可能只需要次日修复。建议把影响范围、是否阻断业务、是否涉及数据和是否需要人工补救写进等级定义，并给每一类配上响应、临时措施和修复目标。
等级定义还要告诉一线员工如何报故障。报错截图、任务编号、发生时间、受影响用户和当前业务状态越清楚，服务商越容易定位。对无法自动判断的情况，可以先按较高等级接收，再由双方确认，不要让员工因为担心报错级别不对而不敢上报。
- 区分确认收到、开始排查、提供绕行方案和彻底修复四个时间点。
- 为涉及客户、付款、合同和数据安全的问题设置升级联系人。
- 约定服务时间和节假日安排，避免默认所有服务都是 7×24 小时。
维护内容和新增需求要分开算
上线后，知识内容会更新，业务规则会调整，员工也会提出新场景。资料更新、提示优化、故障修复、报表调整和新系统接入，性质并不一样。如果全部被称为“优化”，企业不知道哪些已经包含在服务内，服务商也无法安排资源。可以在 SLA 中列出日常维护清单、变更申请方式和超出范围的估算规则。
变更还要有验证和回退。服务商修改了一个回答规则，可能影响十几个页面和多个部门；企业提出新增字段，也可能需要重新评测。每次变更至少留下需求人、影响范围、测试结果和上线时间，避免“改完有效，但没人知道改了什么”。
资料、账号和代码不能随着服务商一起消失
企业应在交付约定中明确自己拥有和可以带走的内容：知识资料、结构化数据、提示和规则版本、接口文档、账号权限、评测样本、操作手册以及日志。第三方工具的许可可能有边界，但企业自己的业务资料和项目记录不能因为合作结束就拿不回来。
退出机制也要提前演练。合作到期、预算变化、服务质量不达标或企业改用内部团队时，谁负责导出，导出什么格式，多久完成，临时过渡期间谁维护，数据如何删除，都需要有路径。真正稳的服务不是把客户锁在流程里，而是交付资料完整到客户可以接手。
验收 SLA，要拿一次真实故障走完整流程
文档写得完整，不代表团队真的能执行。可以在试运行期安排一次低风险演练：模拟资料版本错误、接口短时不可用或一类回答异常，观察员工如何报修、服务商多久确认、谁提供临时方案、最后怎样关闭和复盘。演练中暴露的空白，比上线后第一次真实事故更容易补齐。
每月或每季度复盘 SLA 记录，关注重复故障、超时原因、人工补救、未关闭问题和新增需求积压。服务评价不应只看响应速度，也要看问题有没有被真正解决、企业能不能学会自己判断、交付资料是否持续更新。AI 项目只有进入长期运营，服务承诺才有实际意义。
企业在签服务约定时，还应把“双方需要提供什么”写清楚。服务商需要的可能是脱敏样本、接口权限、业务联系人和变更通知；企业需要服务商提供版本记录、排查结论、操作手册和风险提示。若一方没有按约定提供前置条件，响应时间如何计算也应有说明。把依赖条件写出来，不是推卸责任，而是避免一个问题因为资料没给齐、权限没开通或负责人不在岗，最后变成双方都觉得对方没有履约。
对企业来说，服务商评价也不能只在项目结束时做一次。每个服务周期都可以回看问题是否按时关闭、重复故障有没有减少、变更是否留下记录、业务人员是否找得到支持。若某个问题连续几次被归为“使用方式不对”，就需要双方一起确认是培训缺口、产品设计问题还是服务边界没有写清。这样复盘出来的结论，才会真正帮助下一阶段的交付。
要点总结
- 不需要。先把故障等级、联系人、响应节点、维护范围和退出交接写清楚，比堆很多抽象承诺更有效。
- 要结合业务影响定义。可以约定抽样质量、错误率和人工补救范围，达到阈值后进入问题处理流程。
- 按是否改变约定范围、流程和系统接口判断，并通过变更单记录影响和估算，避免双方靠口头理解。
参考来源说明
本文围绕“AI 服务商承诺很多，交付后谁来负责？合同里要写清响应、修复和退出”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。