AI 功能接进业务系统的三种边界

客户说「给工单系统加个 AI，自动处理」。直接照字面实现就是让 AI 调接口改工单状态——分类错了的单子被自动关闭，客户电话打过来问「我的报修怎么没了」。这类事故的根源不是模型不够准，是没先划边界。

这篇按「AI 接进有状态要改的业务系统」写；只生成文案、不进业务流程的不在此列。

结论一句话：AI 接进业务系统只有三种合法形态，区别只有一条——AI 的输出要不要经过人。三种形态的权限、审计、回滚成本完全不同，永远从最便宜的那档起步：

形态	AI 能做什么	谁确认	失败怎么办
旁路	只读，给分类、摘要、建议	人看完自己操作	AI 错了浪费看的那一眼，业务无损
助手	生成动作草案（改派、回复稿）	人点确认才执行	确认环节拦住，可追溯
自动化	直接调业务接口改状态	无人，事后审计	需要回滚机制和限额，成本最高

用工单场景看旁路怎么落地（下面是示例，细节按真实工单系统定）：工单进来，AI 产出三样东西——分类标签、一句话摘要、建议处理人，全部只写在展示层，客服看一眼点确认，工单状态还是客服手动改的。同一套模型，同样的准确率，AI 错了最多浪费客服一秒钟，工单状态机一个非法迁移都不会发生。

三条注意：

前置条件：旁路转自动化之前，审计日志（每次 AI 产出记输入、输出、置信度、采纳与否，一张 ai_call_log 表的事）和回滚手段（自动化改错的状态要能退回，状态机里预留合法的逆向迁移）两样必须先存在。
最小权限：AI 的账号按最小权限建，它在多租户系统里就是一个特殊「用户」，能用数据权限那一篇的那套办法管住，别共享人的账号。
验收指标：别只看准确率，拒答率和人工兜底率（AI 答不上来、转给人处理的比例）同样进验收单（验收那一篇的口径）；AI 答不上来的时候系统能不能稳稳落回人工，比它答对多少更决定客户观感。