夜雨聆风前阵子，我参与了一个我们公司内部 AI 助手项目。
刚开始我真没觉得这事有多复杂。
老板在会上说了一句：
“公司内部资料这么多，能不能做个 AI 助手？员工以后有问题直接问它。”
你听听，这句话是不是很轻？
说白了，就是知识库接一下，权限打通一下，再把入口放到飞书里。员工问一句，AI 回一句。听起来像个很标准的提效项目。
我当时也这么想。
先做 Demo，跑通效果，再慢慢优化。
两周后，Demo 真做出来了，演示效果还挺顺。
老板问：
“差旅报销标准是多少？”AI 能答，还能带引用来源。
业务的同事问：
“客户投诉这种情况怎么处理？”AI 也能答，流程说得挺完整。
产品经理又追了一句：
“能不能顺手生成一段给客户的回复？”AI 还是能答，语气还挺客气。
说真的，那场演示看起来挺成功。你能明显感觉到会议室里的气氛松下来了，有人点头，有人说这个东西上线以后，群里那些重复问题应该能少一半。
我当时也觉得，至少方向没错。
真正出问题，是后面试点的时候。
销售同事张三（匿名哈，就是经常把客户就是上帝挂在嘴边的差一点成销冠的同事）问了一句特别随口的话：
“那客户现在催我，我能不能把 AI 这段直接贴给他？就按这个说法发。”
我当时就懵了。
不是这个问题有多刁钻，而是它一下子把整个项目从“演示效果不错”，拉回到了真实业务。
AI 引用的那份折扣政策是不是最新版？
这个销售有没有权限看到完整折扣区间？
AI 生成的话术到底算不算公司正式口径？
客户如果拿着这句话回来要求兑现，最后谁负责？
会议室安静了几秒。
那几秒特别真实。
因为你会突然发现，老板嘴里的“AI 助手”，听起来是提效工具。
可到了一线员工手里，它可能会变成工作依据。
再往外一步，到了客户场景里，它甚至可能变成公司承诺。
这个差别太要命了。
我后来才意识到，这个项目最难的地方，根本不是 AI 会不会回答，而是它到底有没有资格回答。
员工问报销制度，AI 答一下，问题不大。
员工问某个客户的合同底价，AI 还能不能答？
客服问赔付流程，AI 可以解释。
可客服让 AI 直接写一段赔付承诺，能不能发出去？
这就不是技术问题了。
你知道吗，一个答得不太好的系统，反而没那么可怕。因为你一看它不靠谱，自然会多留个心眼。
最可怕的是那种答得很像那么回事的系统。
它把制度、案例、流程、语气揉在一起，给你一段完整答案。你看着顺，业务看着也顺，一线员工顺手就复制走了。
问题就在这里。
完整不代表可用。
说得像真的，也不代表能拿去执行。
做这个项目之前，我也会盯着那些技术指标看。
模型选哪个？
知识库怎么切？
召回率怎么测？
引用怎么加？
权限怎么接？
这些当然重要。但做完这个项目以后，我现在会先问另一个问题：
这个 AI 到底能看什么？
项目早期，有人提过一句很自然的话：
“要不先把内部资料都喂进去，资料越多，效果肯定越好。”
说真的，这句话我一开始也没那么警惕。
直到我把第一批准备接入的资料目录拉出来看了一遍。
里面不只有报销制度、产品 FAQ、客户处理流程，还有区域价格表、客户投诉复盘、供应商报价、几份过期政策，甚至还有一些内部会议纪要。
单独看，每个文件好像都还好。
但 AI 不是简单地把文件展示给你看。
它会重新组合信息。
比如销售同事可能会问：
“这个客户最多能让多少？”
如果 AI 同时看到了价格政策、历史折扣、区域策略和客户投诉记录，它很可能给出一个看起来很聪明的答案。
可这个答案，可能已经绕过了原来的权限设计。
以前很多权限是藏在系统里的。
总部能看到一套内容，区域经理能看到一套内容，一线销售只能看到一部分。
菜单、字段、审批流，虽然麻烦，但至少边界还在。
AI 助手不一样。
员工不会一层层点菜单，他只会问一句话。
所以资料不是越多越好。
至少在企业内部场景里，不是。
有些资料可以进知识库。
有些资料只能让 AI 检索标题，不能进入回答上下文。
有些资料根本不能让 AI 读。
还有一个特别容易被忽略的问题：过期文件谁负责下架？
你别小看这个问题。
如果 AI 引用了一份三个月前已经失效的折扣政策，员工照着用了，客户拿着截图回来找公司兑现，最后这锅谁背？
这种事不是改一句提示词就能解决的。
权限问题也是一样。
这个项目里，最早暴露出来的就是权限。
同一个折扣政策，总部、区域经理、一线销售看到的内容不一样。
同一个客户投诉案例，客服可以看处理流程，销售不能看到内部赔付底线。
同一个报价规则，业务负责人可以看完整区间，普通员工只能看到申请流程。
这些东西在传统系统里，你可能觉得挺烦，但它们确实保护了边界。
AI 一接进来，边界就会被重新打开。
比如员工问：
“这个客户能不能特殊处理？”
“这种情况以前有没有赔过？”
“我能不能给他这个承诺？”
你看，这些问题天然会跨系统、跨文档、跨业务口径。
如果 AI 把不同系统的信息拼起来答了，表面看是智能，实际上可能是一个新的权限漏洞。
所以我后来很坚持一件事：
不同角色问同一个问题，答案不一定应该一样。
权限不足时，AI 也不应该硬答。
它要么拒答，要么提示你找谁审批。
这听起来不够“智能”，但对企业来说，这才是正常的。
还有一个坑，是对外话术。
试点的时候，业务同事特别喜欢让 AI 写客户回复。
这我完全理解。
客服、销售、运营这些岗位，每天都要写大量重复内容。让 AI 起个草稿，确实省时间，而且有时候它写得还比人客气。
但“写草稿”和“替公司说话”，不是一回事。
AI 写：
“根据当前流程，建议您先核对订单状态。”
这通常只是协助表达。
但它如果写：
“我们会在三个工作日内为您完成赔付。”
这就变味了。
前一句是建议。
后一句可能就是承诺。
你想一下，一个客户拿着这句话截图回来，说“你们公司答应我三个工作日赔付”，你怎么解释？
你说这是 AI 生成的？
客户不会管。
所以我后来把 AI 输出分成三类。
一类是参考，只给资料、流程和引用来源。
一类是草稿，可以帮员工写话术，但必须人工确认后才能发。
还有一类是结论，可以直接作为业务判断或正式口径。
但说白了，绝大多数企业 AI 助手，前期根本不适合给结论。
尤其涉及价格、合同、赔付、合规、客户承诺、人员评价这些场景，AI 最好先学会拒答。
这话可能不讨业务喜欢。
因为你做 AI，当然希望它越聪明越好。
但我现在的感受是，企业里的 AI 助手，敢拒答比什么都敢答重要多了。
还有责任问题。
项目会上很容易出现一句话：
“先试点看看。”
这句话我也说过。
试点当然要做，不试点很多问题根本看不出来。
但试点不是责任真空。
员工用了 AI 生成的话术，客户投诉了，谁处理？
AI 引用了旧制度，报销判断错了，谁兜底？
AI 把内部口径说成对外承诺，谁来解释？
业务说“这是系统生成的”。
技术说“这是业务资料里的”。
最后谁认？
你看，这种场景太容易发生了。
所以我后来给自己立了一个判断标准：
凡是 AI 输出会影响业务结果的地方，必须有责任人（具体的人而不是AI）。
AI 可以生成。
人必须确认。
系统必须留痕。
而且责任不能全压给技术。
技术负责系统可用性、权限实现、日志追溯。
业务负责规则口径、内容有效性和采纳结果。
产品负责流程设计和用户提示。
测试负责验收集和风险用例。
运维负责监控、告警和暂停机制。
如果这些角色不拆清楚，最后所有人都会默认让技术兜底。
说白了，这不合理，也不安全。
还有一件事，我也是做完这个项目才特别在意。
AI 助手不仅要设计怎么上线，还要设计怎么停。
很多项目聊上线聊得很兴奋。
入口放哪里？
试点给哪个部门？
下一批知识库接什么？
页面怎么做？
可很少有人问：
如果它答错了，谁能把它停下来？
连续出现高风险错误，要不要停？
引用过期政策，要不要停？
出现越权回答，要不要停？
用户投诉集中出现，要不要停？
知识库更新失败，要不要停？
成本突然异常升高，要不要停？
答案来源追溯不了，要不要停？
这些问题听起来不性感，但太现实了。
真实业务不是演示环境。
真实业务里一定会有旧文件、脏数据、误操作、权限变更、临时政策，还有各种奇奇怪怪的问题。
系统不可能永远不犯错。
关键是犯错以后，你能不能发现，能不能暂停，能不能修正，能不能追责。
我现在看一个企业 AI 项目能不能上线，不只看它 Demo 有多顺。
我会看它有没有退出机制。
没有退出机制的 AI 助手，说白了还只是 Demo。
这个项目后来没有被砍掉。
但我也没有继续往上堆功能。
真正让它继续往前走的，不是换了更强的模型，也不是提示词突然写得多神。
而是我先补了一张边界确认表。
这张表不复杂，但每一项都要有人确认。
哪些资料能进 AI，哪些资料禁止读取。
不同岗位能不能看到不同答案。
AI 输出是参考、草稿，还是正式结论。
哪些内容不能直接发给客户。
员工采纳 AI 答案以后，结果由谁负责。
用什么问题集验收引用、拒答、权限和追溯。
出现什么情况必须暂停，暂停后人工流程怎么接。
这张表一出来，很多争议反而简单了。
因为你会发现，AI 助手不是一个单纯的技术需求。
它牵涉数据、权限、业务口径、客户承诺、组织责任和上线治理。
技术可以把系统做出来。
但技术不能替所有部门定义边界。
产品链路我也改了。
原来的链路是：
员工提问，AI 回答，员工自己判断能不能用。
后来改成：
员工提问，AI 检索资料，输出引用、草稿和风险提示，必要时进入人工确认。
看起来只是多了几步，但性质完全不一样。
原来是把 AI 扔给员工。
现在是把 AI 接进流程。
比如制度类问题，AI 可以直接给引用来源。
客户回复类问题，AI 只生成草稿，并提示“需人工确认后对外发送”。
涉及价格、合同、赔付、敏感客户信息时，AI 不再直接回答，而是提示找对应负责人确认。
你看，AI 的能力没有突然变强，但项目变得更能落地了。
企业 AI 项目真正要做的，不是让 AI 看起来更像人。
而是让它在组织流程里有位置、有边界、有记录。
如果下次老板再跟我说：
“我们也做个 AI 助手吧。”
我不会一上来就聊模型、知识库和页面。
我会先问几个问题：
这个 AI 助手能看哪些资料，哪些资料绝对不能看？
不同角色问同一个问题，答案是不是应该一样？
AI 输出的内容，是参考、草稿，还是公司正式口径？
员工用了 AI 答案以后，业务结果由谁负责？
出现越权、错答、投诉、成本异常时，谁有权暂停？
这些问题答不出来，项目不是不能做。
但它还不能进入上线讨论。
最多只能叫 Demo。
我现在对企业 AI 助手有一个很直接的感受。
开发快，不代表交付快。
回答准，不代表能上线。
老板看 Demo 满意，也不代表业务真的能承担结果。
真正能上线的 AI 助手，不一定是回答最多的那个。
而是边界最清楚的那个。
老板说“做个 AI 助手”，技术真正要接住的，不是一句需求。
而是一组责任。
这组责任没人确认，AI 助手越聪明，项目反而越危险。
